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graphic  processing;  and  2)  identifying  methods  by  which  the  amount 
of  displayed  graphic  information  can  be  maximized  without 
sacrificing  clarity  of  presentation.  — 

The  menu-driven  MMI  model  is  recommended  for  AWDS  graphic 
processing,  owing  to  the  numerous  permutations  of  commands  and 
arguments  that  must  be  accounted  for,  and  the  need  to  provide 
on-the-job  training  for  the  user.  The  menu-driven  interface,  a 
computer-initiated  dialogue,  is  better  than  the  two  others  for 
guiding  the  user  through  the  input  process.  Our  findings, 
nevertheless,  showed  that  menu-driven  input  speed  must  be 
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1 . 0  INTRODUCTION 


The  man-machine  Interface  (MMI)  is  a  critical  area  in  the 
development  of  on-line  information  and  C*I  systems  -  users  will 
judge  the  entire  system  based  on  their  experience  with  the  MMI. 

While  the  importance  of  developing  a  good  MMI  is  clear,  the  approach 
to  MMI  requirements  definition  in  system  acquisition  programs  is 
not.  High-level  requirements  for  the  MMI,  as  for  any  system 
software,  are  needed  in  the  System  Specification.  Without  these 
specifications,  the  contractor  will  lack  the  guidelines  to  approach 
MMI  design.  An  ongoing  MITRE  study  [SMIT83a]  is  looking  at  ways  to 
strengthen  MMI  contractual  mechanisms.  Smith's  report  proposes 
approaches  to  Statement  of  Work  (SOW)  tasking,  stipulation  of 
deliverable  data  items,  and  generation  of  system  specifications.  In 
order  to  generate  an  effective  set  of  specifications,  however,  an 
MMI  model  should  first  be  established  in  at  least  a  high-level 
conceptual  sense.  This  paper  explores  one  approach  to  the 
development  of  such  a  model  -  prototyping  and  evaluation  of 
candidate  designs.  The  study  focuses  on  the  MMI  to  the  graphic 
processing  component  of  the  Automated  Weather  Distribution  System 
(AWDS). 

The  mission  of  AWDS  is  to  automate  Air  Force  Base  Weather 
Station  weather  analysis  and  briefing  operations.  MITRE 's  role 
encompasses  technical  assistance  to  the  AWDS  Program  Office  in  the 
areas  of: 

(1)  Preparation  of  the  System  Specification; 

(2)  Technical  evaluation  of  offerors'  proposals;  and 

(3)  Monitoring  of  the  contractor  throughout  the  full-scale 
engineering  development  effort. 

The  AWDS  contract  was  awarded  in  March  1984,  the  same  month  in  which 
this  report  was  issued. 

The  simulation  studies  described  in  this  paper  were  performed 
using  the  AWDS  Graphic  Development  System  (AGDS),  a  set  of 
processors  and  peripherals  that  were  configured  to  emulate  the  AWDS 
Base  Weather  Station  (BWS)  Functional  Area  (FA)  described  in 
Section  3.0. 
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The  use  of  prototyping  for  synthesizing  MMI  requirements  should 
be  considered  for  systems  that  are  expected  to  have  an  intensive 
user-system  interface.  Thus,  this  paper  tries  to  highlight  aspects 
of  the  study  effort  that  are  relevant  to  MMI  design  in  general. 

Much  of  the  text  (especially  Sections  6.0  and  7.0)  addresses 
specific  AWDS-related  details,  but  the  conceptual  investigatory 
strategy  should  be  of  general  interest.  Section  8.0  includes  a 
general  set  of  recommendations  for  MMI  design  support  for  all 
systems.  The  material  in  the  Appendices  is  of  interest  only  to 
those  who  are  well-acquainted  with  AWDS. 
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2 . 0  BACKGROUND 


Graphic  processing,  especially  interactive  graphic 
processing,  is  highly  flexible,  with  an  almost  endless  variety  of 
methods  for  structuring  man-machine  dialogues.  These  methods  range 
from  simple  command  sequences  to  elaborate  menu  hierarchies,  and 
each  can  include  various  levels  of  sophistication  in  the  use  of 
prompting,  help,  user  feedback,  and  error  recovery  mechanisms. 

During  the  past  few  years,  with  the  evolution  of  the  personal 
computer  and  CAD/CAM  systems,  system  designers  have  become  aware 
that  computer  software  must  be  easily  usable  by  the  non-programmer. 
Attention  is  being  focused  on  human  factors  and  ergonomics,  and 
there  has  been  a  concomitant  evolution  in  MMI  design  philosophies. 

As  evidenced  by  newly-developed  systems,  traditional  methods  of 
man-computer  dialogue,  such  as  keyboard  interaction,  may  be  losing 
favor.  Designers  should  be  sensitive  to  contemporary  design 
philosophies  as  candidates  for  on-line  systems.  System  usability 
must  be  a  highly  visible  design  criteria,  because  even  if  all 
requirements  are  successfully  implemented,  a  system  may  be 
considered  a  failure  if  it  is  too  difficult  to  use. 

The  MMI  should  be  a  highly  visible  part  of  the  system 
requirements  definition  phase  in  order  to  achieve  the  goals  proposed 
by  Smith  (SMIT83a].  Suggested  guidelines  for  use  of  prototyping  in 
support  of  MMI  requirements  definition  and  System  Specification 
preparation  are  described  in  Section  8.2.1.  When  the  MMI  cannot  be 
analyzed  in  detail  during  these  early  program  phases,  such  as  was 
the  case  on  AWDS,  then  the  goals  of  a  prototyping  study  must  be 
directed  toward  the  contract  monitoring  phase.  The  AGDS  study 
itself  was  carried  out  in  the  time  period  between  Request  for 
Proposal  (RFP)  release  and  contract  award.  The  specific  goals  of 
the  study  were: 

(1)  To  explore  the  feasibility  of  various  candidate 
designs  for  graphic  processing; 

(2)  To  provide  a  setting  in  which  the  user  (Air  Weather 
Service  (AWS)  and  Air  Force  Communications  Command 
(AFCC))  can  critique  the  candidate  designs  and  help 
select  preferred  approaches.  It  is  hoped  that  this 
information  can  be  provided  to  the  contractor  early 
in  the  contract,  such  as  at  System  Requirements 
Review  (SRR),  to  assist  him  during  the  definition  oT 
graphic  processing  designs; 
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(3)  To  identify  and  resolve  problems  with  the  System 
Specification,  (including  the  Interface  Control 
Drawing  (ICD))  and  actual  candidate  design 
approaches  before  they  are  encountered  by  the 
contractor;  and 

(4)  To  develop  a  set  of  tools  that  can  eventually  be 
applied  to  hands-on  evaluation  of  contractor- 
proposed  design  approaches. 

Two  areas  of  AWDS  graphic  processing  were  selected  for  detailed 
study : 

(1)  Graphic  Display  Presentation  -  The  study  of  methods 
for  optimizing  the  use  of  display  resources  such  as 
resolution  and  color.  The  incentive  for  this  effort 
is  that  AWDS  graphic  display  monitors  can't  provide 
the  high  resolution  traditionally  expected  from 
facsimile  machines  and  hand-drawn  analyses. 

(2)  Graphic  Man-Machine  Interface  -  The  study  of 
possible  logical  interaction  patterns  and  their 
mapping  to  physical  input  devices.  The  incentive 
for  this  effort  is  that,  without  active 
participation  by  the  users  or  a  designated  technical 
support  team,  the  contractor  might  have  to  select  a 
design  approach  Without  the  benefit  of  a  task 
analysis  or  an  understanding  of  operational 
requirements . 

The  study  plan  for  each  area  is  described  in  Section  5.0. 
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3.0  SYSTEM  CONFIGURATIONS 


The  mission  of  the  AWDS  system  is  to  update  Air  Force  Base 
Weather  Station  (BWS)  facilities  and  Notice  to  Airmen  (NOTAM) 
facilities  from  an  era  of  manual,  labor-intensive  operations  to  an 
era  of  automated,  modernized  stations,  where  the  application  of 
available  computer,  display,  and  communications  technologies  will 
provide  more  efficient  use  of  resources  and  more  timely  responses  to 
operational  needs.  AWDS  will  be  deployed  at  Air  Force  and  Army 
bases  worldwide  and  will  be  serviced  by  two  communications  networks. 

A  block  diagram  of  AWDS  appears  in  Figure  1. 

The  Base  Weather  Station  (BWS)  Functional  Area  (FA)  (or  the 
functional ly-equivalent  Staff  Weather  Officer/Wing  Weather  Officer 
(SWO/WWO)  functional  area)  is  the  nerve  center  for  weather 
forecasting  activities  in  AWDS.  The  mission  of  the  BWS  is  to 
prepare  forecasts,  warnings,  and  briefings  for  weather-sensitive 
operations.  The  BWS  encompasses  all  the  graphic  processing 
capabilities  required  for  AWDS,  including: 

(1)  Display  of  externally-generated  vector  graphic  and 
raster  scan  "products”  (such  as  large-scale 
weather  charts);  and 

(2)  Generation  and  display  of  locally-generated 
"composite"  graphic  products  (probably  in  vector 
form),  such  as  regional -scale  weather  charts, 
through  any  combination  of  the  following 
functions : 

(a)  Overlaying  two  or  more  vector  graphic  or 
raster  scan  products; 

(b)  Exercising  a  vector  graphic  product 
generation  function  (such  as  isoplething)  on 
raw  weather  data  that  is  contained  in 
Formatted  Binary  Data  (FBD)  or  Uniform 
Gridded  Data  Field  (UGDF)  products;  and 

(c)  Adding  or  modifying  vector  graphic  product 
information  using  the  graphic  interaction 
function . 

The  AWDS  System  Specification  [OCR-AWDS-01]  does  not  dictate  a 
complete  hardware  configuration  for  the  BWS,  although  it  does  specify 
the  following  minimum  requirements: 
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AFGWC:  AIR  FORCE  GLOBAL  WEATHER  CENTRAL 


(1) 

Two  512  X  512  (nominal), 
monitors ; 

eight-color  graphic  display 

(2) 

One  24-line-by-80-column 

alphanumeric  terminal; 

(3) 

One  keyboard; 

(4) 

One  graphic  tablet;  and 

(5) 

One  graphic/alphanumeric  hardcopy  device  (could  be 
shared  with  other  functional  areas). 

The  hardware  configuration  selected  for  the  AGDS  (see  Figure  2) 
emulates  the  BWS  configuration  for  a  distributed  AWDS  architecture. 
We  opted,  however,  for  one  high  resolution  graphic  display  monitor 
rather  than  two  medium  resolution  monitors  because  we  wanted  to; 

(1)  Emulate  two  physical  512  x  512  monitors  using  two 
512  X  512  logical  viewports;  and 

(2)  See  whether  the  additional  informational  content 
displayable  on  a  higher  resolution  monitor  would  be 
a  significant  aid  to  various  operational  tasks. 

The  AGDS  configuration  includes  three  alphanumeric  terminals  for  the 
support  of  program  development  in  a  multiple-user  environment.  The 
nine-track  tape  drive  and  the  floppy  disk  drive  were  included  for 
Winchester  disk  backup,  and  for  information  transfer  with  other 
systems.  A  graphic  hardcopy  capability  does  not  currently  exist  on 
the  AGDS. 
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Figure  2.  AGDS  Configuration 


4.0  MAN-MACHINE  INTERFACE  CONSIDERATIONS 


MMI  design  requires  the  designer  to  pay  attention  to  human 
factors  and  ergonomics.  Most  investigators  would  agree  that  the 
field  of  MMI  design,  particularly  for  graphics,  is  in  its  youth; 
while  much  is  known,  MMI  design  is  still  more  of  an  art  than  a 
science.  There  are  a  variety  of  guidelines  for  the  good  practice 
design  of  MMI,  but  one  cannot  show  deterministically  that  a  particu¬ 
lar  MMI  approach  is  best  for  a  given  type  of  system  or  application. 

A  comprehensive  discussion  of  MMI  design  concepts  is  beyond  the  scope 
of  this  paper;  for  an  in-depth  treatment,  "Fundamentals  of  Interac¬ 
tive  Computer  Graphics"  by  J.  D.  Foley  and  A.  Van  Dam  [F0LE82]  is 
recommended. 

The  purpose  of  this  section  is  to  introduce  a  few  key  MMI 
design  principles,  and  to  discuss  special  considerations  relating  to 
AWDS.  In  addition,  this  section  surveys  other  Automated  Weather 
Information  Systems  (AWIS),  and  notes  points  of  interest  relating  to 
AWDS  MMI  design. 


4.1  General  Considerations 


According  to  Foley  and  Van  Dam,  the  most  important  guidelines 
for  the  design  of  interactive  programs  are: 

"(1)  Provide  simple,  consistent  interaction  sequences; 

(2)  Do  not  overload  the  user  with  too  many  different 
options  and  styles  for  communicating  with  the 
program; 

(3)  Prompt  the  user  at  each  stage  of  the  interaction 
(but  allow  the  more  experienced  user  to  bypass 
prompts) ; 

(4)  Give  appropriate  feedback  to  the  user;  and 

(5)  Allow  graceful  recovery  from  mistakes." 

Another  key  element  to  consider  is  the  experience  of  the  system 
user.  Foley  and  Van  Dam  recognize  three  experience  levels:  "novice 
users,  who  are  just  learning  the  basic  concepts  and  mechanics  of  the 
system;  intermediate  users,  who  have  learned  to  do  some  productive 
work  and  are  now  building  proficiency  and  learning  additional  system 
capabilities;  and  experienced  users,  who  are  proficient  in  all  or 
most  system  aspects  and  who  know  all  of  the  system  capabilities 
(some  systems  have  so  many  capabilities  that  users  are  experienced 
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only  with  certain  sets  of  frequently  used  capabilities)." 
Understandably,  novice  users  are  more  comfortable  with  systems  that 
guide  them  through  the  intricacies  of  input,  while  the  experienced 
users  are  better  served  by  systems  that  are  optimized  for  speed  of 
use.  It  is  a  challenging  task  to  accommodate  the  needs  of  all  three 
user  groups.  Often,  an  effective  compromise  is  an  MMI  that 
incorporates  prompting  and  help  facilities  that  can  be  used  by  the 
novice,  and  bypassed  (possibly  in  incremental  steps)  as  the  user 
gains  experience. 

The  determining  factor  in  the  success  of  MMI  design  is  often 
not  the  ability  of  the  system  designers,  but  the  development  costs 
involved  -  a  dichotomy  of  ease  of  implementation  versus  ease  of  use. 
Ideally,  the  development  of  the  MMI  is  carried  out  in  a  logical 
manner,  as  follows: 

(1)  Develop  an  understanding  of  the  problem  and  the 
prospective  users; 

(2)  Develop  an  operational  concept  for  the  system; 

(3)  Design  the  MMI  in  a  top-down  fashion; 

(4)  Implement  (code)  MMI  functions;  and 

(5)  Refine  the  MMI  through  a  test  and  evaluation 
procedure  involving  the  prospective  user. 

When  budget  or  schedule  constraints  exert  pressure  to  get  the  system 
running  as  soon  as  possible,  designers  may  not  allot  sufficient  time 
to  develop  a  thoughtful  design.  The  resulting  design  may  be 
inadequately  detailed  and  be  fraught  with  internal  inconsistencies; 
the  final  system  itself  can  be  deplorable,  or  at  least  very 
frustrating  to  use. 


4 . 2  AWDS-Specif ic  Considerations 

According  to  the  System  Specification,  AWDS  equipment  shall  be 
designed  for  operation  by  enlisted  military  technicians  of  skill 
level  five.  It  takes  the  enlisted  weather  technician  three  or  four 
years  to  attain  level-five  proficiency.  He  or  she  must: 

(1)  Complete  a  six-month  course  in  weather  observing 
techniques  and  practices; 
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(2)  Obtain  two  or  three  years  of  experience  as  a 
weather  observer; 

(3)  Complete  a  six-month  course  in  weather 
forecasting;  and 

(4)  Finally,  demonstrate  level-five  proficiency  on  the 
job  (often  just  a  formality  for  one  who  has 
completed  the  forecasting  course) . 

Air  Force  Specialty  Training  Standard  (STS)  251X0  describes  the 
tasks,  knowledge,  and  study  references  necessary  for  airmen  to 
perform  duties  in  the  Weather  Ladder  of  the  Airman  Weather  Career 
Field.  For  weather  analysis,  a  key  function  that  will  require  an 
intensive  user-system  dialogue  when  transferred  to  AWDS,  the  STS 
shows  that  the  weather  technician  can  be  qualified  at  level  five 
with  only  a  "nomenclature"  "Task  Knowledge  Level"  proficiency 
(nomenclature  is  the  lowest  of  four  levels),  and  no  (not  even  an 
"extremely  limited")  "Task  Performance  Level"  proficiency.  The  same 
skill  ratings  also  apply  for  weather  forecasting  and  briefing.  The 
STS  does  not  currently  include  proficiency  standards  for  computer 
usage  skills,  although  this  must  change  in  the  AWDS  era,  when  AWDS 
equipment  will  be  used  in  the  training  courses.  For  weather 
technicians  already  in  the  field  when  AWDS  is  deployed,  a  two-  or 
three-week  training  course  will  be  provided. 

The  profile  that  emerges  for  the  novice  user  is  that  of  a 
person  who  will  be  learning  how  to  do  his  job  at  the  same  time  he  or 
she  is  learning  how  to  use  the  system.  This  user  group  will  need  an 
easy-to-use  system. 

The  needs  of  the  user  after  becoming  experienced  with  AWDS  are 
not  as  clear.  The  aggregate  complexity  of  AWDS  may  prevent  the 
expert  from  becoming  proficient  for  all  but  a  subset  of  commonly 
used  commands.  As  discussed  further  in  Section  6.1.3,  there  are 
more  than  100  separate  ordinal  combinations  of  commands  and 
arguments  in  the  graphic  processing  area  alone,  and  an  almost 
endless  number  of  possible  permutations  of  command/argument  values. 
The  complexity  stems  from  the  fact  that  AWDS  will  likely  carry  a 
running  inventory  of  2775  individual  products,  many  of  which  can  be 
used  as  input  data  sets  for  a  number  of  different  applications 
functions.  It  appears,  therefore,  that  even  the  experienced  user 
would  frequently  make  use  of  available  support  features. 


4 . 3  Survey  of  Other  Automated  Weather  Information  Systems 

There  are  Automated  Weather  Information  Systems  (AWIS)  in 
operation  today  that  bear  functional  similarities  to  AWDS.  As  an 
aid  to  requirements  definition,  the  AWDS  team  studied  and  even 
visited  many  of  these  systems.  We  were  interested  in  learning  about 
users'  reactions  to  the  particular  man-machine  interfaces  employed. 
Table  1  lists  some  of  the  more  noteworthy  AWIS  studied,  their 
missions,  dates  of  deployment  (or  initial  operation),  and  the  MMI 
styles  used.  The  earlier  systems  relied  exclusively  on  command  line 
syntax  input.  Users  of  the  Man-Computer  Interactive  Data  Access 
System  (McIDAS)  (who  are  generally  of  high  experience  level)  felt 
that  the  command  line  syntax  is  preferable  because  it  is  fast;  but 
in  contrast,  users  of  the  Automation  of  Field  Operations  and 
Services  (AFOS)  at  the  Boston  National  Weather  Service  (NWS) 

Forecast  Office  were  observed  to  have  difficulty  performing 
non-commonly  used  functions. 

The  Prototype  Regional  Observing  and  Forecasting  Service 
(PROFS)  is  the  most  influential  system  in  operation  today  because 
its  goal  has  been  to  develop  and  operationally  test  a  prototype 
system  that  could  replace  AFOS  in  NWS  offices  by  the  early  1990's. 
The  PROFS  program  has  supported  a  full-time  MMI  design  team,  and  has 
actively  solicited  experimentation  with  the  system  by  personnel  from 
all  sectors  of  the  meteorological  community.  Users  have  reacted 
favorably  to  the  menu-driven  interface  structure  (which  is  mapped  to 
a  touch  panel  overlaying  a  graphic  monitor  dedicated  to  display  of 
menus).  The  PROFS  MMI  shields  the  user  from  low-level  data  set 
retrieval  details,  enabling  the  user  to  rapidly  produce  a  display 
through  fingertip  selection  of  familiar  weather  parameters.  While 
the  physical  implementation  of  the  PROFS  MMI  may  not  be 
cost-effective,  anyone  associated  with  AWDS  cannot  overlook  the 
widespread  enthusiasm  with  which  the  PROFS  menu-driven  MMI  has  been 
embraced.  PROFS  points  out  a  clear  direction  for  future  AWIS  MMI. 
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5.0  THE  AGDS  STUDY  PLAN 


The  AGDS  study  plan  was  prepared  in  January,  1983,  and  has  been 
closely  followed  throughout  the  effort.  The  study  plan  outlined  a 
set  of  tasks  to  be  performed  under  the  graphic  display  presentation 
and  graphic  MMl  study  areas.  The  original  study  plan  appears  in 
Appendix  A. 


5 . 1  Man-Machine  Interface  Study  Plan 

The  study  plan  for  the  MMI  area  identified  three  conceptual 
models  that  could  be  considered  as  candidates  for  the  graphic  MMI: 

(1)  A  command  line  syntax  structure; 

(2)  A  prompted  entry  structure;  and 

(3)  A  menu-driven  structure. 

All  three  structures  have  been  used  in  many  systems,  and  do  not 
appear  to  introduce  any  conflicts  with  the  System  Specification. 
These  structures  are  described  in  detail  in  Section  6.1.3. 

One  also  needs  to  study  how  the  designs  should  map  to  logical 
and  physical  input  devices.  In  AWDS,  the  physical  input  devices 
include,  as  a  minimum,  a  keyboard  and  a  graphic  tablet.  Ergonomic 
considerations  favor  the  use  of  a  single  input  device  for  control  of 
a  given  function  or  family  of  functions,  but  this  is  not  always 
possible  if  "natural"  mappings  are  exploited  (e.g.,  the  mapping  of 
text  string  input  to  a  physical  keyboard). 

Although  the  MMI  study  has  since  been  expanded  to  include  all 
AWDS  graphic  processing  functions,  the  original  study  plan  focused 
on  the  interfaces  to  two  key  sets  of  functions;  the  horizontal 
analysis  composite  product  functions  and  the  zoom  and  graphic 
interaction  functions.  The  horizontal  analysis  composite  product 
functions  comprise  a  set  of  tools  (such  as  display,  isopleth,  plot, 
and  streamline)  used  to  create  analyses  of  the  weather  on  background 
maps.  The  graphic  interaction  functions  provide  an  interactive 
capability  to  add,  delete,  relocate,  and  highlight  features  on 
graphic  products.  The  zoom  functions  allow  the  user  to  magnify 
selected  areas  of  products. 

Details  of  the  graphic  MMI  study  are  described  in  Section  6.0. 
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5 . 2  Graphic  Display  Presentation  Study  Plan 

The  study  plan  for  graphic  display  presentation  identified  two 
tasks : 

(1)  The  study  of  graphic  depictions  of  various  weather 
symbology;  and 

(2)  The  study  of  data  density  and  product  complexity 
levels  for  various  graphic  products. 

Because  of  the  limited  display  screen  resolution  specified  for  AWDS, 
care  must  be  taken  to  maximize  informational  content.  Insufficient 
informational  content  makes  it  difficult  for  the  weather  forecaster 
to  analyze  or  mentally  integrate  weather  patterns.  The  goal  of  the 
first  task  was  to  study  how  weather  symbology  can  be  displayed  in  a 
manner  that  is  legible,  but  economical  in  terms  of  display  size. 
Three  types  of  weather  symbology  studied  are; 

(1)  Meteorological  symbols  -  pixel  pattern 
representations  of  weather  symbols  such  as  rain, 
snow,  and  thunderstorms; 

(2)  Parameter  plot  models  -  organized  arrangements  of 
meteorological  symbols  and  alphanumeric  characters 
that  depict  the  weather  at  observation  stations;  and 

(3)  Symbolic  lines  -  polylineal  or  polygonal  weather 
features  such  as  weather  fronts  and  cloud  and 
precipitation  area  outlines. 

The  study  plan  for  data  density  and  product  complexity  levels 
for  graphic  products  was  aimed  at  determining  how  much  information 
(e.g. ,  number  of  parameter  plots,  number  of  isopleths,  amount  of  map 
background  detail)  could  be  clearly  displayed  on  both  medium  and 
high  resolution  graphic  monitors.  The  results  of  this  task  provide 
guidelines  for  the  design  of  functions  used  to  create  locally- 
generated  products,  and  suggest  limits  for  the  complexity  of 
externally-generated  products. 

Details  of  the  graphic  display  presentation  study  are  described 
in  Section  7.0. 


6.0  MAN-MACHINE  INTERFACE  STUDY 

This  section  describes  the  approach  used  to  develop  the  three 
candidate  man-machine  interfaces,  and  points  out  their  advantages 
and  disadvantages.  Design  of  the  interfaces  to  the  zoom  and  graphic 
interaction  functions  is  discussed  separately.  Implementation  of 
selected  functions  is  described  in  Section  6. A. 


6 . 1  Design  of  Strawman  Interfaces 

The  design  of  man-machine  interfaces,  as  is  the  case  with  all 
software,  should  be  approached  in  a  top-down  fashion.  However, 
since  the  System  Specification  proceeded  MMI  conceptual  model 
development,  and  not  /ice  versa,  a  modified  progression  of  design 
steps  was  followed: 

(1)  Prepare  a  checklist  of  Specification  requirements 
for  operator  interaction,  and  identify  those 
relating  to  graphic  processing; 

(2)  Develop  a  strawman  hierarchy  of  MMI-related  graphic 
processing  functions; 

(3)  Formulate  candidate  conceptual  MMI  models  (e.g., 
command  line  syntax); 

(4)  For  each  model,  postulate  logical  interaction 
patterns,  define  logical  input  devices  and  the 
mapping  of  logical  input  devices  to  physical  input 
devices;  and 

(5)  Include  mechanisms  for  prompting,  help,  user 
feedback,  and  error  recovery. 

The  first  two  steps  extract  and  logically  organize  functional 
requirements,  and  the  third  step  defines  the  conceptual  MMI  models. 
Steps  4  and  5  define  the  semantic  design  (operations  performed  and 
their  effects),  the  syntactic  design  (user's  logical  actions  and 
their  effects),  and  the  lexical  design  (binding  of  language  tokens 
to  physical  actions). 


6.1.1  Design  Step  1 


In  the  first  step,  AWDS  MMI  requirements  were  identified  and 
categorized  according  to  three  main  types:  alphanumeric,  graphic, 
and  control.  To  facilitate  this  task,  the  following  definitions 
were  adopted; 
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(1)  The  alphanumeric  category  shall  apply  to  those 
actions  necessary  for  the  creation,  modification, 
acquisition,  and  disposition  of  alphanumeric 
products  and  computation  results; 

(2)  The  graphic  category  shall  apply  to  those  actions 
necessary  for  the  creation,  modification, 
acquisition,  and  disposition  of  graphic  products; 
and 

(3)  The  control  category  shall  include  computer 
operations,  login/ logout  procedures,  and  management 
of  control  tables. 

Appendix  B  contains  the  complete  list  of  Specification  requirements 
for  MMI  and  their  categorization. 


6.1.2  Design  Step  2 


In  the  second  step  of  the  process,  a  strawman  hierarchy  was 
developed  for  all  MMI-related  graphic  functions.  The  hierarchy 
defines  all  inputs  needed  for  complete  specification  of  a  function 
to  be  performed  and  a  data  set  on  which  to  perform  that  function. 
For  AWDS,  operator  inputs  are  of  the  following  types: 

(1)  Commands  -  for  example,  display  and  isopleth; 

(2)  Data  Set  Selection  -  specification  of  sufficient 
information  for  unique  retrieval  of  a  product  by  its 
eight-field  product  identifier  structure  and  valid 
time  (as  discussed  in  the  AWDS  Interface  Control 
Drawing  (ICD)); 


(3)  Display  Control  -  identification  of  the  monitor  on 
which  the  display  will  appear;  and 

(4)  Other  n  ,  iments  -  arguments,  often  optional,  which 
control  :ow  the  function  is  performed  or  how  the 
display  will  appear  (for  example,  plot  model 
selection  or  data  override  information). 


The  second  type  of  operator  input,  data  set  selection,  will  be 
examined  in  detail  in  Section  8.1.2.  To  ensure  that  every  product 
could  be  uniquely  identified  and  retrieved,  it  was  assumed  that  each 
component  of  the  product  identifier  must  be  matched  to  an  equivalent 


17 


1 


retrieval  key.  The  only  exceptions  permitted  were:  1)  omission  of 
a  retrieval  key  for  the  File  Indicator  (F)  for  all  products, 
reflecting  a  general  understanding  that  it  is  not  necessary  for 
retrieval;  and  2)  elimination  of  retrieval  keys  for  the  "ii"  and 
"EE"  fields  for  Formatted  Binary  Data  (FBD)  products.  (For  FBD 
products,  these  fields  describe  a  reporting  station  grouping  scheme 
that  is  not  helpful  for  retrieval  of  all  weather  observations  within 
a  given  geographical  area.) 

The  complete  strawman  hierarchy  is  presented  in  Appendix  C. 
Although  the  hierarchy  appears  to  represent  a  hierarchy  of  menus, 
the  hierarchy  is  independent  of  any  logical  or  physical  MMI 
implementation.  The  "menu"  entries  represent  possible  or  allowable 
input  values,  not  methods  for  selecting  them.  Appendix  C  also 
includes  a  set  of  notes  and  assumptions  relating  to  the  hierarchy. 
Many  of  these  notes  describe  ways  in  which  specific  MMI  requirements 
can  fit  within  the  general  hierarchical  framework.  These  methods 
should  be  given  consideration  for  actual  implementation  in  AWDS. 


6.1.3  Design  Step  3 

In  the  third  step,  three  candidate  models  were  defined: 

(1)  A  command  line  syntax  structure; 

(2)  A  prompted  entry  structure;  and 

(3)  A  menu-driven  structure. 

The  command  line  syntax  is  categorized  as  a  user-initiated  dialogue 
because  the  user  controls  the  input  and  selects  options  without 
being  presented  an  explicit  set  of  alternatives.  The  prompted  entry 
and  menu-driven  structures  are  categorized  as  computer- initiated 
dialogues  because  the  system  takes  the  initiative  in  guiding  the 
user  through  the  input  process. 

The  command  line  structure  is  based  on  input  of  a  single-line 
string  of  text  that  includes  the  function  and  its  associated 
arguments.  The  syntax  is  of  the  form: 

command/arg.  1/arg.  2/.../arg.  n 

The  command  line  structure  is  rather  inflexible  and  requires  the 
operator  to  remember  the  correct  order  of  input.  For  AWDS,  this 
could  cause  confusion  for  anyone  but  the  most  experienced  user 
because  the  type  of  inputs  and  order  of  inputs  often  vary  depending 
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on  inputs  previously  entered.  According  to  the  hierarchy  in 
Appendix  C,  there  are  more  than  100  separate  paths  through  the 
hierarchy  for  AWDS  graphic  functions  alone.  This,  coupled  with  the 
need  to  know  the  set  of  allowable  values  (and  allowable 
abbreviations  of  values)  of  each  input,  imposes  a  formidable 
memorization  problem.  Normally,  the  entire  command  line  syntax  is 
input  before  the  command  is  parsed  by  the  system,  although  a  help 
function  can  be  accommodated  that  when  invoked,  will  parse  the 
portion  of  the  command  already  entered,  and  will  provide  help  for 
the  next  required  input  in  the  command  line  syntax. 

The  prompted  entry  structure  removes  the  burden  of  memorizing 
the  order  of  input  by  guiding  the  operator  through  a  decision  tree 
input  process.  It  is  of  the  form: 

Command?  [operator  response] 

Argument  1?  [operator  response] 

Argument  2?  [operator  response] 


Argument  n?  [operator  response] 

The  structure  leads  the  operator  along  a  unique  path  through  the 
hierarchy  and  prompts  the  user  for  parameter  input  at  each  level. 

The  prompted  entry  is  amenable  to  the  incorporation  of  various  help 
features  such  as  listings  of  allowable  input  values  (and 
abbreviations),  required  input  formats,  and  default  values. 

The  menu-driven  structure  also  implicitly  incorporates  order  of 
parameter  input  by  leading  the  operator  through  a  series  of  menus 
that  list  allowable  values  for  each  input.  The  menus  are  of  the 
form: 


(page  1) 

(page  2) 

(page  n) 

Command 

Argument  1 

Argument  n-1 

Command  1 

Value  1 

Value  1 

Command  2 

Value  2  •  •  • 

Value  2 

Command  m 

Value  m 

Value  m 
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The  list  of  allowable  values  for  each  argument  could  include  all 
conceivable  possibilities,  or  only  those  possibilities  that,  given 
the  values  already  input,  will  lead  to  the  identification  of  a 
meaningful  function  and  a  meaningful  data  set  on  which  to  perform 
that  function.  Implementation  of  the  latter  option  eliminates  the 
possibility  of  erroneous  or  meaningless  input.  The  implementation 
of  the  menu-driven  interface  on  the  AGDS  uses  a  combination  of  the 
two  methods:  all  possible  values  are  listed,  and  "meaningful" 
values  are  highlighted.  (Since  the  AGDS  is  not  intended  to  be  a 
mini-AWDS,  very  little  of  the  full  AWDS  functionality  is  available, 
and  few  values  are  highlighted.) 

As  a  specific  example  of  the  three  MMI  structures,  assume  that 
the  operator  wants  to  isopleth  surface  pressure  using  hourly  surface 
observations,  as  described  in  Table  2.  The  resulting  isobars  are 
overlayed  on  a  background  map  (see  Figures  3-5  for  examples).  The 
implementation  of  this  function  is  given  in  Table  3  for  each 
interface  structure.  Note  that  for  the  command  line  syntax  and 
prompted  entry  structures,  argument  abbreviations  can  be  used,  if 
known . 


6.1.4  Design  Step  4 

The  fourth  step  in  the  top-down  design  of  candidate  man-machine 
interfaces  involves  formulating  logical  interaction  patterns, 
identifying  a  set  of  logical  input  devices  for  interacting  with  MMI 
software,  and  then  mapping  these  logical  input  devices  to  physical 
input  devices.  For  this  study,  we  considered  the  set  of  logical 
input  devices  identified  by  the  Graphical  Kernel  System  (GKS),  a 
device- independent  graphic  programming  standard  supported  by  the 
International  Standards  Organization  (ISO)  and  the  American  National 
Standards  Institute  (ANSI).  Table  4  describes  the  general  purpose 
of  each  logical  device,  and  identifies  appropriate  ways  in  which  the 
devices  can  be  used  in  operation  with  AWDS  functional  requirements. 
Each  of  the  logical  devices  is  then  mapped  to  one  of  the  physical 
input  devices  required  by  the  System  Specification:  the 
alphanumeric  keyboard  or  the  graphic  tablet.  Finally,  recognizing 
the  Importance  of  user  feedback  in  human  factors  design,  the  Table 
identifies  the  appropriate  physical  output  (echo)  device. 

Following  the  relationships  established  in  the  Table,  the 
candidate  man-machine  interfaces  for  command  line  entry  and  prompted 
entry,  which  require  Intensive  text  string  input,  have  primarily 
been  mapped  to  the  alphanumeric  keyboard  and  monitor.  The 
menu-driven  interface,  which  relies  on  picking  of  menu  entries,  has 
primarily  been  mapped  to  the  graphic  tablet  and  monitor. 
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Table  2 


Isopleth  Function  Example 


Functional  Type:  Horizontal  Analysis  Composite  Product  Function 
Function:  Isopleth 

Monitor:  1 

Data  Indicator:  Formatted  Binary  Data 
Data  Designator:  Hourly  Surface  Reports 
Surface  Parameter:  Pressure 

Valid  Time;  1200  GMT  Today 
Isopleth  Levels:  Default 
Data  Override;  No  Override 
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Table  3 


Three  Implementations  for  the  Isopleth 
Function  Example 

1 .  Command  Line  Syntax  Implementation 
ISOPLETH/ 1/FORMATTED  BINARY/ SURFACE/ PRESSURE/ 1200 .TODAY/// 

2 .  Prompted  Entry  Implementation 

FUNCTION? 

MONITOR  (1,  2)? 

DATA  INDICATOR? 

DATA  DESIGNATOR? 

SURFACE  PARAMETER? 

VALID  TIME? 

ISOPLETH  LEVELS? 

DATA  OVERRIDE? 
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Table  3  (continued) 


3.  Menu-Driven  Implementation 


Cycle  through  the  following  menus  (from  Appendix  C)  in  order 


1.1 

1.1.6 

1. 1.6.1 

1.1.6. 1.1 

1.1.6. 1.1.1 

1.1. 6. 1.1. 1.1 

1.1. 6. 1.1. 1.1.1 


Return  to  Menu  1.1  upon  completion. 
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Mapping  of  Logical  Input  Devices  to  Physical  Input  Devices 


There  are  exceptions  to  these  relationships.  The  first 
exception,  relating  to  the  menu-driven  interface,  allows  text  string 
input  from  the  alphanumeric  keyboard  when  it  cannot  be  avoided.  An 
example  is  the  key-in  of  a  user-defined  label  by  which  a 
locally-generated  product  is  subsequently  stored.  (Retrieval  of  a 
locally-generated  product  would,  however,  be  driven  from  a  menu  of 
labels  for  available  locally-generated  products.)  The  second 
exception,  relating  to  the  command  line  syntax  and  prompted  entry 
structures,  concerns  a  few  key  functions,  most  notably  the  zoom  and 
graphic  interaction  functions,  which  are  graphically  interactive  by 
nature.  The  graphic  interaction  functions  and  zoom  functions  can  be 
invoked  by  any  of  the  three  interface  structures,  but  it  is  felt  (and 
actually  driven  by  the  System  Specification)  that  the  mechanics  for 
carrying  out  these  functions  naturally  map  to  the  pick  and  locator 
logical  input  devices  and,  hence,  the  graphic  tablet  physical  input 
device.  Thus,  in  the  study  of  candidate  interface  structures,  the 
zoom  and  graphic  interaction  functions  are  dealt  with  separately  from 
the  three  candidate  interfaces  (See  Section  6.3). 


6.1.5  Design  Step  5 

The  final  step  in  the  top-down  design  of  candidate  interfaces 
involves  fine-tuning  the  designs  to  maximize  their  ease  of  use. 
Mechanisms  for  prompting,  help,  user  feedback,  and  error  recovery  were 
considered  for  each  candidate  design.  This  area  was  given  cursory 
attention  because  the  goal  of  the  study  was  to  compare  and  contrast 
the  high-level  utility  of  each  candidate  design,  not  to  dwell  on 
low-level  detailed  implementations. 


6 . 2  Comparison  of  the  Three  Interface  Styles 

Table  5  draws  a  comparison  between  the  three  interface  struc¬ 
tures.  Evaluation  of  the  speed  of  use  criterion,  comparing  novice 
and  experienced  users,  is  based  on  our  own  judgement  ^ince  we  did  not 
have  the  opportunity  to  test  the  designs  on  a  candidate  users  group. 
It  is  expected  that  the  menu-driven  interface  could  be  operated  by 
both  novice  and  experienced  users  with  about  equal  proficiency.  As 
discussed  in  Section  8.1.2,  entry  via  the  menu-driven  interface  could 
be  accelerated  if  a  concise  relationship  between  product  retrieval 
keys  and  product  identifier  fields  was  established.  Input  speeds  for 
the  novice  versus  experienced  user  are  expected  to  rapidly  diverge 
when  the  menu-driven  Interface  style  is  replaced  by  either  the  com¬ 
mand  line  syntax  or  prompted  entry.  For  the  experienced  user,  the 
command  line  syntax  would  be  quicker  to  use  than  the  menu-driven 
Interface  (for  at  least  a  commonly-used  subset  of  the  full  function¬ 
ality),  but  for  the  novice  user,  the  command  line  syntax  might  be 
impossible  to  use. 
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Concerning  ease  of  implementation,  the  time  to  implement  the  MMI 
for  a  given  function  was  found  to  be  largely  independent  of  the 
interface  style.  The  design  effort  involved  in  developing  the  graphic 
hierarchies  in  Appendix  C  applies  equally  to  each  model. 
Correspondingly,  the  same  programming  logic  was  implemented  to 
instruct  the  system  how  to  respond  to  operator-selected  parameter 
values  once  parsed.  The  only  differences  -  and  they  are  minor  - 
relate  to  implementing  the  MMI  dialogue  itself.  The  command  line 
syntax  does  not  require  prompting,  but  command  parsing  is  more  complex 
because  of  the  freer  format  of  the  command,  and  the  need  to  recognize 
abbreviations  of  parameter  value  names.  By  comparison,  graphic  menus 
are  straightforward  to  implement  with  a  high-level  subroutine  package 
(e.g.,  GKS-based) ,  and  selection  of  parameter  values  is  simple  because 
it  works  by  position  designation,  not  by  recognition  of  names  or 
abbreviations.  Thus,  ease  of  implementation  does  not  depend  on  the 
MMI  model  selected,  but,  in  all  cases,  it  is  strongly  (and  inversely) 
influenced  by  the  effort  expended  in  developing  ancillary  features 
such  as  help,  user  feedback,  and  error  recovery  mechanisms. 

The  error  potential  criterion  measures  the  susceptibility  of  each 
interface  style  to  user  input  errors.  The  command  line  syntax  is  most 
prone  to  errors  because  it  is  sensitive  to  both  erroneous  parameter 
values  and  invalid  order  of  input.  The  prompted  entry  is  less 
susceptible  because  it  removes  the  need  to  memorize  order,  but  still 
leaves  most  of  the  burden  of  selection  of  valid  values  to  the  user. 

Tile  menu-driven  interface  will  be  minimally  error  prone  if  menus  are 
updated  in  real  time  to  reflect  those  data  sets  currently  available 
for  the  function  being  performed.  Ease  of  error  recovery  is  somewhat 
dependent  on  the  sophistication  of  prompting  and  help  facilities 
provided  with  the  interface  structure.  For  the  command  line  syntax, 
bad  parameter  values  may  not  be  detected  until  input  is  complete  and 
the  command  is  parsed  as  a  whole.  Depending  on  the  implementation, 
the  user,  at  best,  will  be  able  to  correct  individual  parameter 
values,  and,  at  worst,  will  be  forced  to  retype  the  entire  command 
(and  may  not  even  be  told  what  he  did  wrong).  The  prompted  entry  and 
menu-driven  structures  are  more  amenable  to  graceful  error  recovery 
because  error  checking  (to  any  level  of  sophistication)  can  be 
performed  following  each  parameter  input.  This  feature  also  tends  to 
simplify  implementation. 

Contention  for  the  alphanumeric  terminal  will  result  when 
concurrent  use  by,  or  input  for,  graphic  and  alphanumeric  functions  is 
precluded.  If  graphic  processing  functions  are  controlled  by  the 
alphanumeric  terminal,  contention  will  result  when,  for  example,  the 
operator  uses  a  full-screen  alphanumeric  form  to  enter  information 
obtained  by  recalling  and  viewing  a  series  of  graphic  products. 
Contention  for  the  alphanumeric  terminal  could  be  minimized  by 
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partitioning  the  screen  to  include  a  small  viewport  for  graphic- 
related  input,  but  this  might  not  be  feasible  for  the  prompted  entry 
structure's  more  wordy  question-and-answer  dialogue. 


6.3  Graphic  Interaction  Functions  and  Zoom  Functions 

As  discussed  earlier,  the  graphic  interaction  functions  and  zoom 
functions  are  interactive  in  nature.  These  functions  may  be  invoked 
by  any  of  the  three  candidate  interface  structures ,  but  the  lower 
level  mechanics  intrinsic  to  carrying  out  these  functions  are 
independent  of  the  driving  interface  structure. 

The  graphic  interaction  functions  and  zoom  functions  are 
described  as  follows: 

(1)  Add  Symbol  -  Add  a  selected  weather  symbol  at  a 
selected  location; 

(2)  Add  Symbolic  Line  -  Draw  a  line  in  a  selected  line 
style  (e.g.,  cold  front); 

(3)  Add  Character  -  Add  a  selected  alphanumeric 
character  at  a  selected  location; 

(4)  Add  Text  String  -  Add  a  text  string  at  a  selected 
location; 

(5)  Delete  Segment  -  Delete  a  selected  graphic  segment 
(e.g.,  symbolic  line,  station  parameter  plot)  from 
the  display; 

(6)  Highlight  Segment  -  Highlight  a  selected  graphic 
segment ; 

(7)  Relocate  Segment  -  Relocate  (as  by  dragging)  a 
segment  on  the  display; 

(8)  Polygon  Fill  -  Fill  a  selected  polygon  (e.g.,  a 
closed  symbolic  line)  on  the  display; 

(9)  Zoom  A  -  Magnify  (by  pixel  replication)  the  display 
around  a  selected  zoom  centerpoint  and  permit 
roaming  (if  desired);  and 

(10)  Zoom  B  -  Magnify  (without  pixel  replication)  the 
display  around  a  selected  zoom  centerpoint  and 
increase  the  number  of  displayed  station  parameter 
plots.  Roaming  is  not  required. 
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One  example  of  the  use  of  these  functions  is  weather  frontal 
analysis,  a  task  for  which  no  dependable  objective  algorithm  is 
available.  The  analyst  is  trained  to  position  fronts  accurately  by 
examining  parameter  plots  for  all  available  surface  reporting 
stations  within  the  general  vicinity  of  a  given  front,  and 
recognizing  signatures  revealed  by  the  simultaneous  geographic 
variation  of  parameters  such  as  temperature,  dewpoint  temperature, 
pressure,  barometric  tendency  and  characteristic,  and  wind 
direction.  In  AWDS ,  this  task  will  be  carried  out  using  the  Plot, 
Add  Symbolic  Line,  and  Zoom  B  functions. 

Each  graphic  interaction  function  or  zoom  function  could  be 
implemented  in  a  variety  of  different  ways.  Rather  than  explore  an 
endless  number  of  possibilities,  the  goal  was  to  design,  implement, 
and  fine-tune  a  single  procedure  for  each  function.  Care  was  taken 
to  incorporate  helpful  design  techniques,  such  as: 

(1)  Dragging  -  Allow  the  user  to  reposition  a  graphic 
segment  with  real-time  display  of  its  resultant 
motion ; 

(2)  Software  generation  of  line  styles  -  When  drawing  a 
symbolic  line,  the  user  need  only  provide  the  line 
path.  The  software  will  subsequently  redraw  the 
line  in  the  proper  symbolic  line  style;  and 

(3)  Partial  line  modification  -  Rather  than  forcing  the 
user  to  delete  and  then  redraw  the  entire  line,  the 
software  allows  the  user  to  redraw  only  the  portion 
of  interest. 

The  strawman  implementation  of  each  function  is  described  in 
Table  6.  The  Table  describes  each  procedural  step,  identifies  the 
appropriate  logical  input  device,  and  describes  how  feedback  is 
provided  to  the  user  following  input.  The  pick,  locator,  and  button 
logical  devices  were  mapped  to  three  physical  buttons  on  the  graphic 
tablet  stylus  (four  are  provided).  The  remaining  button  is  used  for 
an  escape  function,  allowing  the  user  to  abort  the  current  graphic 
interaction  or  zoom  function,  and  return  to  the  original  processing 
state  (i.e.,  no  changes  are  accepted). 


6 . 4  Implementation  of  AWDS  Application  Functions 

There  was  no  need  to  develop  a  "mini-AWDS"  because  the 
interfaces  to  all  but  intensively  interactive  functions  can  be 
studied  without  implementing  the  functions  themselves.  For  various 
reasons,  however,  a  few  selected  functions  were  implemented.  These 
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Implementation  of  the  Graphic  Interaction  Functions  and  Zoom  Functions 
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Table  6  (Continued) 
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functions  belong  to  two  functional  sets:  the  horizontal  analysis 
composite  product  functions  (display,  plot,  isopleth,  streamline, 
etc.),  and  the  graphic  interaction  and  zoom  functions.  The  two 
functional  sets  embody  important  complementary  aspects  of  graphic 
processing  and  will  receive  heavy  use  in  AWDS.  The  display  function 
was  implemented  for  demonstration  purposes,  to  simulate  an  AWDS 
response  after  invoking  a  function.  The  isopleth  function  was 
implemented  to  measure  response  times  as  part  of  another  study.  The 
parameter  plot  function  was  implemented  to  produce  a  resolution¬ 
intensive  display  for  analysis  in  the  graphic  display  presentation 
study  area.  The  zoom  and  graphic  interaction  functions  were,  as 
mentioned  previously,  implemented  because  they  could  not  otherwise 
be  studied  from  a  MMI  point  of  view. 

Figures  3-5  are  photographs  of  the  graphic  display  screen  that 
illustrate  the  execution  of  these  functions  within  the  context  of 
the  menu-driven  structure.  Figure  3  shows  the  output  (weather 
fronts  and  isobars)  of  the  display  function  in  a  1024  x  1024 
viewport.  The  background  map  consists  of  approximately  7000 
vectors.  The  menu  viewport  shows  hierarchy  module  1.1.5  (data 
indicator),  meaning  that  the  operator  is  in  the  process  of  carrying 
out  the  isopleth  function.  The  "formatted  binary"  menu  entry  is 
color-coded  (not  apparent  in  the  black-and-white  photograph), 
indicating  that  this  type  of  data  is  available  in  the  data  base. 

Figure  4  shows  the  output  from  the  isopleth  (isobars  are  shown) 
and  plot  functions.  It  illustrates  a  display  option  that  was 
implemented  to  allow  us  to  emulate,  through  pixel  replication,  a 
512  X  512  full-screen  display.  The  plot  model  is  an  early  attempt 
at  creating  the  surface  standard  parameter  plot,  without  visibility 
and  barometric  tendency  and  characteristic  (see  Section  7.1.2).  The 
menu  viewport  shows  an  early  version  of  the  horizontal  analysis 
composite  product  command  menu  (hierarchy  module  1.1  in  Appendix  C). 

Figure  5  show  how  two  512  x  512  viewports  can  be  used  to 
emulate  two  physical  512  x  512  AWDS  monitors.  The  right  viewport 
shows  weather  fronts  produced  by  the  display  function.  The  left 
viewport  shows  isobars  produced  by  the  isopleth  function.  The  menu 
viewport  illustrates  the  "add  character"  graphic  interaction 
function.  The  user  has  selected  in  order,  as  they  appear 
dynamically,  the  letter  "L",  the  color,  character  size,  and  line 
width;  and  is  in  the  process  of  placing  the  character  in  the  left 
viewport . 
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7.0  GRAPHIC  DISPLAY  PRESENTATION  STUDY 

The  graphic  display  presentation  study  area  encompassed  two 
tasks : 

(1)  The  study  of  graphic  depictions  of  various  weather 
symbology;  and 

(2)  The  study  of  data  density  and  product  complexity 
levels  for  various  graphic  products. 


7 . 1  Display  of  Weather  Symbology 

This  study  area  focused  on  the  definition  of  candidate 
depictions  for  weather  symbols,  parameter  plot  models,  and  symbolic 
lines  on  AWDS  graphic  displays.  Due  to  the  resolution  requirements 
for  AWDS  graphic  monitors,  a  balance  between  clarity  and  display 
space  must  be  achieved  to  maximize  informational  content. 

Three  routines  were  developed  on  the  AGDS  to  facilitate  the 
creation  and  display  of  symbols,  parameter  plot  models,  and  symbolic 
lines . 


7.1.1  Symbols  Routine 

The  symbols  routine  provides  the  capability  to  create  and 
display  up  to  five  pixel  pattern  depictions  (instances)  for  each  of 
the  symbols  listed  in  Table  30.4.12  of  the  System  Specification. 

The  symbols  are  stored  in  an  indexed  file  structure  and  are 
displayed  in  their  actual  pixel  pattern  representation  as  well  as  a 
pixel-replicated  representation  that  simulates  their  appearance  on  a 
512  X  512  monitor.  Font  size  is  also  shown.  The  symbols  program 
provides  four  options: 

(1)  Display  all  instances  of  a  symbol; 

(2)  Add  a  pixel  pattern  instance  by  filling  squares  in 
a  20  X  20  grid  template; 

(3)  Modify  a  pixel  pattern  instance  by  filling  and 
deleting  squares  on  the  grid  template;  and 

(4)  Delete  an  unwanted  ^stance  of  a  symbol. 
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Several  candidate  instances  of  each  symbol  were  implemented  to 
illustrate  tradeoffs  between  legibility  and  economy  of 
representation.  Font  sizes  that  provide  the  best  balance  are: 

(1)  Present  Weather  -  11  x  11  font  size,  except  for 
blowing  dust  (7  x  17),  heavy  snow  (17  x  16),  shower 
with  mixed  rain  and  snow  (7  x  16),  thundershower 
with  mixed  rain  and  snow  (16  x  18),  and  past  weather 
-  blowing  dust  (14  x  17); 

(2)  Cloud  Type  -  11  x  11  font  size; 

(3)  Cloud  Amount  Total  -9x9  font  size;  and 

(4)  Barometric  Characteristic  -7x5  font  size. 

These  font  sizes  do  not  include  a  blank  border  surrounding  the 
lighted  pixels. 

Figures  6  and  7  illustrate  the  use  of  the  symbols  program. 

Both  figures  show  the  display  of  all  available  instances  of  six 
meteorological  symbols;  1)  shower  during  the  past  hour  (WPH); 

2)  cumulonimbus  with  anvil  (CB9);  3)  ground  fog  (GF) ;  4)  severe 
turbulence  (TBS);  5)  tropical  storm  -  southern  hemisphere  (TSS); 
and,  6)  snow  grains  (SG) .  Each  symbol  instance  is  displayed  (in 
its  default  color)  in  both  its  actual  and  its  pixel-replicated 
(equivalent  512  x  512)  representation.  Figure  6  shows  the  menu  used 
to  select  the  symbol,  the  symbol  instance  (if  appropriate),  and  the 
operation  to  be  performed.  Figure  7  illustrates  the  addition  or 
modification  of  a  symbol  instance  (in  this  case,  an  instance  of  WPH) 
using  the  grid  template.  Upon  completion,  the  user  can  decide  to 
keep  or  discard  the  newly  added  or  modified  symbol  instance. 

7.1.2  Parameter  Plot  Model  Routine 

The  parameter  plot  model  routine  displays  surface  parameter 
plots  for  al*  (or  a  subset  of)  the  reporting  stations  within  a  map 
area.  The  standard  surface  plot,  depicted  in  Figure  8,  includes  the 
parameters  and  display  formats  described  in  Table  7.  A  strict 
interpretation  of  the  requirements  for  the  surface  plot,  as  depicted 
in  Figure  9,  requires  a  rectangular  display  area  of  67  x  36  pixels. 
Figure  9  uses  a  character  size  of  6  x  8  pixels,  a  popular  size.  On 
the  512  X  512  viewport,  these  characters  are  large  enough  to  meet 
the  Specification  requirement  that  characters  on  a  graphic  monitor 
shall  subtend  a  minimum  of  20  minutes  of  vertical  arc  at  a  viewing 
distance  of  20  inches.  On  the  1024  x  1024  viewport,  however,  a 
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Figure  8.  A  Typical  Standard  Surface  Parameter  Plot 


Table  7 


Parameters  and  Formats  for  the  Standard 
Surface  Parameter  Plot 


Cloud  Amount  Total 


The  symbol  for  cloud  amount  total  is  centered  at  the  geographic 
location  of  the  reporting  station. 

Wind  Direction 


A  solid  line  (wind  shaft)  is  drawn  extending  outward  from  the  cloud 
amount  total  symbol  toward  the  direction  from  which  the  wind  is 
blowing.  If  the  wind  speed  is  calm,  rather  than  drawing  the  shaft, 
a  circle  is  drawn  concentrically  around  the  cloud  amount  total 
symbol . 

Wind  Speed 

Solid  lines  (wind  barbs)  and/or  solid  triangles  (wind  pennants)  are 
drawn  perpendicularly  from  the  wind  shaft.  A  short  barb  represents 
five  knots,  a  long  barb  represents  10  knots,  and  a  pennant 
represents  50  knots . 

Present  Weather 


The  present  weather  symbol  is  displayed  to  the  left  of  the  cloud 
amount  total  symbol. 

Temperature 

A  three-digit  numerical  value  (e.g.,  -12)  for  temperature  in  degrees 
Celsius  is  displayed  above  the  present  weather  symbol. 

Dewpoint  Temperature 

A  three-digit  numerical  value  for  dewpoint  temperature  in  degrees 
Celsius  is  displayed  below  the  present  weather  symbol. 

Visibility 

A  three-digit  numerical  value  (e.g.,  124  for  12-4/8  miles)  is 
displayed  to  the  left  of  the  present  weather  symbol. 
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Table  7  (continued) 


Pressure 


A  three-digit  numerical  value  (e.g.,  528  for  952.8  or  1052.8 
millibars  -  the  hundreds -digit  and  thousands -digit  are  dropped)  is 
displayed  to  the  upper  right  of  the  cloud  amount  total  symbol. 

Barometric  Tendency  and  Characteristic 

A  three-digit  numerical  value  (e.g.,  125  for  a  change  of  .125  inches 
of  mercury)  and  the  symbol  for  characteristic  (which  indicates  the 
sign  of  the  change)  are  displayed  to  the  lower  right  of  the  cloud 
amount  total  symbol. 
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Figure  9.  Layout  of  the  67  x  36  Standard  Surface  Parameter  Plot  Model 


9  X  12  font  is  needed  to  meet  the  same  requirement.  The  Specifi¬ 
cation  is  more  relaxed  for  character  size  on  an  alphanumeric  monitor 
-  characters  need  to  subtend  only  15  minutes  of  arc.  If  higher 
resolution  graphic  monitors  were  adopted  for  AWDS,  the  more  relaxed 
character  size  would  be  adequate  for  characters  in  plot  models  - 
readability  of  these  characters  is  not  more  critical  than 
readability  of  text. 

The  plot  program  alternately  allows  the  user  to  reduce  the 
overall  plot  model  size  by  the  selection  of  one  or  more  display 
options : 

(1)  Eliminate  the  space  for  calm  wind  circle  and,  as  an 
alternative,  highlight  (color  code)  the  cloud  amount 
total  symbol  when  winds  are  calm; 

(2)  Move  the  visibility  to  the  right  of  the  cloud  amount 
total  symbol  (thereby  making  the  parameter  plot  more 
symmetric,  and  reducing  rectangular  area); 

(3)  Use  alternate  representations  of  the  five  outsized 
present  weather  symbols  so  that  the  font  size  needed 
to  accommodate  all  present  weather  symbols  can  be 
reduced  from  17  x  18  to  11  x  11; 

(4)  Eliminate  the  minus  sign  for  negative  temperature 
and  dewpoint  temperature  values,  and,  as  an 
alternative,  highlight  (color  code)  negative  values; 
and 

(5)  Exploit  the  variable  vertical  extent  of  (or  the 
possible  absence  of)  the  present  weather  symbol  by 
allowing  the  temperature  and  dewpoint  temperature 
fields  to  be  dynamically  repositioned  downwards  and 
upwards,  respectively. 

Selection  of  Options  1,  2,  3,  and  4,  collectively,  reduces  the 
rectangular  size  of  the  parameter  plot  model  to  44  x  29  pixels  (see 
Figure  10),  again  based  on  a  6  x  8  character  font  size.  Concurrent 
selection  of  Option  5  will  further  shrink  the  upper  left  and  lower 
left  corners  of  the  plot  model. 

Display  of  the  wind  flag  (wind  speed  and  direction)  also  needs 
to  be  considered.  Because  the  wind  shaft  orientation  is  a  function 
of  wind  direction,  the  wind  flag  often  tends  to  impinge  on  other 
displayed  parameter  plot  variables,  degrading  overall  readability. 
One  way  to  minimize  this  problem  could  be  to  eliminate  wind  barbs 
and  represent  wind  speed  by  color-coding  the  wind  shaft.  If 
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Figure  10.  Layout  of  the  4A  x  29  Standard  Surface  Parameter  Plot  Model 


the  shaft  was  divided  into  three  piecewise  line  segments,  individual 
color  codings  could  be  used  to  denote  the  number  of  five-knot  wind 
speed  increments  (0  or  1),  ten-knot  increments  (0  to  4),  and  50-knot 
increments  (0,  1,  or  more),  that  sum  to  give  the  actual  wind  speed. 

Section  7.2  describes  how  selection  of  the  various  options  for 
reducing  parameter  plot  model  size  can  increase  the  total  number  of 
plots  displayable  on  the  graphic  monitor. 


7.1.3  Symbolic  Lines  Routine 


The  symbolic  lines  routine  supports  the  creation  and  display  of 
symbolic  lines  such  as  weather  fronts  and  outlines  of  cloud  or 
precipitation  areas.  For  each  symbolic  line,  the  program  permits 
selection  of  composition  parameters  that  determine  the  appearance  of 
the  line.  For  weather  fronts  (cold,  warm,  stationary,  and  occluded 
fronts),  these  parameters  include  line  width,  pip  size,  and  pip 
spacing.  Tests  suggest  that  weather  fronts  should  be  composed  as 
follows : 


(1)  Weather  frontal  lines  should  be  at  least  twice  as 
wide  as  isopleth  lines; 

(2)  Pips  should  be  one  to  two  times  as  large  as  the 
alphanumeric  characters  in  parameters  plots;  and 

(3)  Pip  spacing  should  be  five  to  ten  times  the  pip 
width. 


7 . 2  Product  Complexity  Levels 

This  study  focused  on  determining  how  much  information  should 
be  included  in  externally-generated  products  (e.g.,  large-scale 
weather  charts)  and  locally-generated  products  (e.g. ,  regional-scale 
weather  charts).  Product  complexity  levels  depend  on: 

(1)  Size  and  number  of  station  parameter  plots 
(locally-generated  products  only); 

(2)  Number  of  isopleths  and  symbolic  lines;  and 

(3)  Resolution  of  the  map  background. 

For  station  parameter  plots,  the  goal  was  to  determine  how  many 
plots  could  be  clearly  displayed  on  a  map  of  the  Northeastern  United 
States  (825  square  nautical  miles).  There  are  far  too  many  surface 
stations  in  the  area  for  display  on  a  512  x  512  graphic  monitor. 
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even  with  a  simple  parameter  plot  model.  Recognizing  this  problem, 
the  Specification  allows  for  a  display  prioritization  scheme, 
whereby  the  number  of  displayed  stations  per  unit  geographical  area 
increases  as  a  function  of  the  Zoom  B  zoom  ratio  (lx,  2x,  4x,  8x, 
and  16x  magnification).  Table  8  shows  how  many  station  plots  can  be 
displayed,  without  physical  overlap  of  parameters  between  adjacent 
plots,  for  each  zoom  ratio,  and  for  various  viewport  resolution  and 
plot  model  combinations.  The  test  data  set  contained  weather 
observations  for  172  surface  stations  in  the  region.  The  "standard" 
plot  is  as  depicted  in  Figure  9,  and  the  "condensed"  plot  is  as 
depicted  in  Figure  10.  As  described  in  Section  7.1.2,  "normal" 
characters  are  6x8  pixels,  and  "large"  characters  are  9  x  12 
pixels.  Tests  show  that  the  normal  character  size  could  be  used  on 
the  1024  X  1024  viewport  with  little  loss  in  readability  compared  to 
the  large  character  size  -  and  with  a  significant  gain  in  the  number 
of  displayable  parameter  plots. 

Increasing  the  zoom  ratio  dramatically  increases  the  number  of 
displayable  parameter  plots,  especially  at  lower  zoom  ratios,  oov. 
of  the  higher  resolution  viewport  is  equivalent  to  doubling  the  zoom 
ratio,  without  decreasing  overall  display  area.  As  a  result,  the 
16:1  zoom  ratio,  which  in  any  case  produces  a  map  scale  too  small 
for  relevance  to  synoptic  scale  analysis,  is  hardly  necessary  for 
the  1024  X  1024  viewport. 

The  use  of  the  condensed  plot  in  place  of  the  standard  plot  did 
not  make  a  large  difference  in  the  number  of  parameter  plots 
displayable  without  overlap  -  but  the  numbers  in  Table  8  are 
misleading.  We  found  that,  owing  to  the  asymmetry  and  sparse 
configuration  of  the  standard  plot,  its  use  led  to  a  cluttered 
display,  and  it  became  difficult  to  associate  displayed  parameters 
with  the  correct  surface  station,  even  when  no  physical  overlap 
occurred.  For  the  standard  plot  in  the  512  x  512  viewport,  the 
practical  upper  limit  was  36  rather  than  48  plots  for  the  1:1  zoom 
ratio.  The  additional  20  station  plots  that  can  be  added  using  the 
condensed  plot  would  be  very  helpful  in  tasks,  such  as  weather 
frontal  analysis,  where  the  forecaster  needs  to  derive  a  mental 
picture  of  the  weather  over  a  geographical  area. 

While  parameter  plots  are  a  critical  resolution  driver, 
isopleths  and  symbolic  lines  are  not.  The  512  x  512  viewport  seems 
to  provide  adequate  resolution  for  display  of  several  parameter 
fields,  although  clutter  makes  it  difficult  to  assimilate  more  than 
three  at  the  same  time,  even  for  the  higher  resolution  viewport. 
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Number  of  Parameter  Plots  Oisplayable  as  a  Function  of 
Viewport  Resolution,  Plot  Model,  and  Zoom  Ratio 


The  map  background  must  have  adequate  resolution  to  enable  the 
operator  to  distinguish  small-scale  geographic  features  at  a  16x 
zoom  ratio.  The  Specification  allows  for  27,000  vectors  per  map 
background.  The  AGDS  clearly  shows,  however,  that  for  a 
Northeastern  United  States  map  background  containing  only  7000 
vectors,  familiar  small-scale  geographic  features,  such  as  Cape  Cod, 
are  unmistakable  at  a  16x  zoom  ratio. 


8.0  CONCLUSIONS  AND  RECOMMENDATIONS 


A  prototyping  tool,  such  as  the  AVniS  Graphic  Development 
Systems  (AGDS),  can  aid  requirements  definition  for  man-machine 
interfaces  to  on-line  systems.  For  AWDS,  the  AGDS  studies  were 
effective  in  formulating  a  number  of  key  recommendations  for  the 
design  of  MMI  and  graphic  display  presentation  functions.  These  are 
summarized  in  Section  8.1. 

As  a  corollary  to  this  effort,  recommendations  for  the  general 
application  of  system  simulation  studies  in  system  acquisition 
programs  are  discussed  in  Section  8.2. 


8 . 1  Specific  Conclusions  of  the  Study 

Three  categories  of  conclusions  and  recommendations  for 
specific  application  to  AWDS  have  emerged  from  the  AGDS  studies: 

1)  those  relating  to  the  MMI;  2)  those  relating  to  the  Interface 
Control  Drawing  (ICD)  product  identifier  structure  which  strongly 
influences  the  MMI;  and  3)  those  relating  to  graphic  display 
presentation. 


8.1.1  Man-Machine  Interface 


If  a  single  interface  structure  is  selected  for  AWDS,  the 
menu-driven  interface  appears  to  be  more  desirable  than  either  the 
command  line  syntax  or  the  prompted  entry  structure.  Some  key 
reasons  are; 

(1)  The  menu-driven  interface  is  the  best  at  guiding 
the  user  through  the  input  process,  a  primary 
design  factor  considering  the  aggregate  complexity 
of  AWDS  and  the  probable  overall  inexperience  of 
the  novice  AWDS  user; 

(2)  The  menu-driven  interface  would  be  reasonably 
quick  to  use  if  the  product  identifier  structure 
were  simplified  (see  Section  8.1.2); 

(3)  The  menu-driven  interface  frees  up  the 
alphanumeric  terminal  for  dedicated  support  of  the 
many  alphanumeric  processing  functions  that  are 
part  of  AWDS;  and 
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(4)  The  basic  menu-driven  framework  does  not  appear  to 
be  more  complex  to  implement  than  the  other  two 
interface  structures. 

These  reasons  reflect  the  rationale  that,  if  a  tradeoff  must  be 
made,  the  need  for  comprehensive  user  support  is  more  critical  than 
the  need  for  speed  of  use.  As  discussed  in  Section  4.2,  the  novice 
user  will  probably  be  learning  how  to  do  his  job  at  the  same  time  he 
is  learning  how  to  use  the  system.  Further,  the  system  may  be  so 
complex  that  even  the  operator  who  is  both  an  experienced  weather 
technician  and  AWDS  user  would  be  better  served  by  a  system- 
initiated  dialogue  when  performing  certain  sets  of  commands. 

The  best  MMI  solution,  however,  would  be  to  combine  the 
menu-driven  and  command  line  syntax  structures  into  a  single 
interface  structure.  If  properly  designed,  this  combination  would 
facilitate  ease  of  use  by  employing  a  self-teaching  feature  to 
accelerate  the  transition  from  use  of  the  menu-driven  structure  to 
use  of  the  command  line  syntax.  To  accomplish  this,  the  two  input 
styles  should  be  completely  interchangeable  on  a  parameter-by- 
parameter  basis.  Selection  of  a  menu  item  should  produce  an  echo  of 
the  equivalent  command  line  syntax  representation  in  a  viewport 
adjacent  to  the  menu  viewport  on  the  graphic  screen,  allowing  the 
user  to  visualize  how  a  command  line  is  built.  As  the  user  becomes 
more  familiar  with  the  system,  he  could  graduate  to  use  of  the 
command  line  entry  in  a  self-paced  fashion. 


8.1.2  Product  Identifier  Structure 


The  speed  of  command  entry  directly  depends  on  the  number  of 
input  steps  involved,  and,  for  menu-driven  structure,  the  number  of 
entries  in  each  menu  (since  it  takes  a  finite  amount  of  time  to 
display  each  entry).  To  accelerate  input  speed,  the  baseline 
assumption  (see  Section  6.1.2)  of  equivalence  between  product 
identifier  fields  and  retrieval  keys  needs  to  be  challenged.  The 
product  identifier  allows  for  a  considerable  amount  of  redundancy, 
irrelevant  parameters,  and  invalid  parameter  combinations  - 
variability  that  should  not  be  manifested  in  the  retrieval  function. 
The  solution  to  this  problem  could  be  achieved  without  altering  the 
basic  structure  of  the  product  identifier,  only  its  application.  It 
should  first  be  agreed  which  product  identifier  fields  are 
unnecessary  for  unique  product  identification  and  retrieval  -  these 
could  be  blank-filled  when  transmitted  and/or  ignored  by  AWDS  for 
later  product  retrieval.  Then  a  set  of  rules  could  be  established 
that  describe  which  possible  values  of  the  remaining  product 
identifier  fields  are  valid  on  a  product  type  basis.  These  lists 
could  be  extended  later  if  the  contractor  ensures  that  his  MMI 
design  is  flexible. 
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Some  specific  suggestions  for  simplifying  product 
identification  and  retrieval  are: 

(1)  Eliminate  the  need  for  the  File  Indicator  (F)  as  a 
retrieval  key  (this  is  already  reflected  in  the 
hierarchy  presented  in  Appendix  C); 

(2)  Eliminate  the  need  for  the  Data  Type  Subcategory 
(TT)  as  a  retrieval  key; 

(3)  Eliminate  the  need  to  specify  UGDF  mesh  size  and 
UGDF  and  Pixel  Product  packing  format  as  part  of 
the  Data  Type  Indicator  (D) ; 

(4)  Eliminate  multiple  part  numbers  from  the  Base 
Time/Part  Number  field; 

(5)  Eliminate  the  possibility  for  combining  into  a 
single  product  two  or  more  parameters  listed  for 
the  Parameter  and  UGDF  Mnemonic  field;  and 

(6)  Eliminate  the  PI  Set  Code  and  replace  it  with  the 
Geographic  Designator  (AA) ,  eliminating  the 
confusion  and  associated  slowness  of  input  caused 
by  the  use  of  two  separate  geographical 
indicators . 

Adoption  of  these  suggestions  would  reduce  the  hierarchies  described 
in  Appendix  C  to  a  set  of  inputs  familiar  to  any  weather  forecaster 
-  e.g.,  function,  parameter,  time,  geographical  area,  and 
atmospheric  level.  These  changes  could  also  accelerate  menu-driven 
input  to  the  point  where  it  would  not  be  significantly  slower  than 
command  1 ine  input . 


8.1.3  Graphic  Display  Presentation 

Several  recommendations  emerged  from  the  graphic  display 
presentation  study  area.  These  are: 

(1)  Limit  the  font  sizes  to  11  x  11  for  present 
weather,  11  x  11  for  cloud  type,  and  9x9  for 
cloud  amount  total; 

(2)  Adopt  modified  11  x  11  pixel  pattern 
representations  for  the  five  outsized  present 
weather  symbols; 
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(3)  Adopt  the  suggestions  for  shrinking  the  surface 
standard  plot  model  to  44  x  29  pixels;  and 

(4)  Limit  map  backgrounds  to,  at  most,  10,000  vectors. 


The  study  also  showed  that  a  higher  resolution  monitor  would 
facilitate  interactive  weather  analysis  because  a  larger  number  of 
parameter  plots  could  be  displayed  simultaneously. 


8 . 2  General  Recommendations  for  Use  of  Prototyping  Studies 

As  a  contract  monitor  in  an  acquisition  program,  visibility 
into  the  MMI  design  process  is  necessary  to  enhance  the  overall 
success  of  a  system.  The  MMI  should  be  studied  from  the  start  of 
the  acquisition  process  in  order  to  fold  high-level  requirements  for 
MMI  design  into  the  System  Specification.  System  simulation  studies 
can  also  be  influential  in  a  contract  monitoring  relationship  to 
ensure  that  the  MMI  design  progresses  in  the  right  direction.  This 
requires  that  the  contract  monitor  demonstrate  credibility  and 
insight  into  the  particular  MMI  design  problem,  qualities  best 
obtained  through  system  simulation  studies. 

The  following  sections  provide  suggestions  for  using  system 
simulation  studies  for  approaching  MMI  development  as  a  requirements 
definition  activity  and  as  a  contract  monitoring  tool. 


8.2.1  Man-Machine  Interface  Requirements  Definition 

The  first  logical  step  in  MMI  design  is  to  perform  a  user 
requirements  study  and  task  analysis  to  develop  an  understanding  of 
the  problem  area  and  the  prospective  user,  and  to  study  how  the  user 
performs  his  job  in  the  current  environment.  The  task  analysis 
should  provide  a  set  of  functional  requirements  to  be  made  available 
through  the  MMI.  Once  these  functional  requirements  are  understood, 
the  MMI  design  can  be  formulated.  A  top-down  design  approach  will 
define,  in  order,  the  conceptual  design  (the  high-level  MMI  model), 
the  semantic  design  (operations  performed  and  their  effects),  the 
syntactic  design  (user's  logical  actions  and  their  effects),  and  the 
lexical  design  (binding  of  language  tokens  to  physical  actions). 
Requirements  definition  for  the  higher  levels  in  the  top-down  design 
approach  is  consistent  with  the  goals  of  a  System  Specification. 

With  the  higher  level  model  in  hand,  the  tools  provided  by  Smith 
(SMIT83aJ  can  then  be  applied  to  generate  a  tailored  set  of  system 
specifications . 
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In  summary,  system  simulation  studies  can  be  used  to: 


(1)  Develop  candidate  MMI  models  and  test  them  on  the 
prospective  user; 

(2)  Identify  problems  with  the  application  of  a  given 
model  that  might  otherwise  be  overlooked; 

(3)  Use  the  results  of  (1)  and  (2)  as  an  input  to 
Smith's  methodology  for  defining  MMI  requirements 
for  the  System  Specification;  and 

(4)  Thereby,  reduce  risks  associated  with  leaving  the 
entire  MMI  development  job  to  the  contractor. 
These  risks  include: 

a)  Insufficient  budgeting  for  design  and 
implementation  of  the  MMI,  and 

b)  Cost  growth  on  contract  if  the  Government 
finds  the  resulting  MMI  to  be  unsuitable. 


8.2.2  Monitoring  Man-Machine  Interface  Development 

High-level  MMI  design  guidelines,  based  on  system  simulation 
studies,  can  alternatively  be  provided  to  the  contractor  as 
non-binding  information  at  early  requirements  reviews,  such  as 
System  Requirements  Review  (SRR)  or  System  Design  Review  (SDR). 

This  is  recommended  on  the  AWDS  program.  If  the  proposed  MMI  model 
does  not  conflict  with  other  design  plans  (such  as  those  that 
reflect  use  of  existing  contractor  software),  then  the  contract 
monitor  has  a  good  chance  of  influencing  the  MMI  in  a  positive 
direction. 

Prototyping  studies  can  also  be  a  useful  evaluation  tool 
through  Critical  Design  Review  (CDR) .  If  the  simulation  system  is 
composed  of  a  core  of  functions  relevant  to  the  conceptual  model 
described  by  the  System  Specification  and/or  adopted  by  the 
contractor,  then  it  can  be  easily  applied  to  test  key  elements  (and 
users'  reactions  to  those  elements)  of  the  contractor's  design. 
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STUDY  AREA  #1  -  GRAPHIC  DISPLAY  PRESENTATION 


The  incentive  for  the  graphic  display  presentation  study  area 
comes  from  the  fact  that  AWDS  graphic  display  monitors  will  not  be 
able  to  provide  the  high  resolution  traditionally  expected  from 
facsimile  machines  and  hand  analyses.  The  plot  function  has  been 
identified  as  a  particularly  severe  resolution  driver.  It  is, 
therefore,  critical  to  devise  methods  promoting  highly  efficient  use 
of  display  resources.  Optimum  use  of  display  resources  will  be 
achieved  through  economic  representation  of  weather  symbols  and 
features,  intelligent  use  of  color,  careful  partitioning  of  display 
screens  into  viewports,  and  use  of  tools  such  as  the  zoom  B 
function.  Clarity  in  the  presentation  of  data  cannot  be  sacrificed. 

Sample  tasks  in  the  graphic  display  presentation  study  area 

are ; 

1.1  Selection  of  an  optimum  font  size  for  meteorological  symbols 
(present  weather  and  cloud  type): 

Set  up  and  display  pixel  pattern  representations  of  weather 
symbols  (Table  30.4.12  of  the  AWDS  Specification)  using  several 
different  candidate  font  sizes  (e.g.,  6x8,  10  x  14,  15  x  20). 

1.2  Depiction  of  the  standard  plot  model: 

1.2.  a.  Given  the  optimum  symbol  font  sizes  selected  above, 

implement  the  plot  function  and  determine  an  optimum 
standard  plot  model  size. 

1.2. b.  Examine  how  intelligent  use  of  color  could  be  used 

to  improve  plot  model  clarity  and  to  reduce  optimum 
plot  model  size.  For  example,  if  the  wind  barb 
tends  to  obscure  underlying  plot  data,  investigate 
whether  use  of  color  (or  reverse  video)  can  correct 
this . 

1.3  Display  requirements  for  LAWC  plot  fields: 

1.3.  a.  Display  the  background  map  and  the  two  vector 

graphic  products  and  determine  how  many  station 
parameter  plots  can  be  displayed  at  the  1:1  zoom 
ratio. 


1.3.b.  Use  the  windowing  algorithm  in  the  Lexidata  software 
to  simulate  the  zoom  function,  and  determine  how 
many  station  parameter  plots  can  be  displayed  at 
various  higher  zoom  ratios. 

1.4  Depiction  of  symbolic  lines: 

Determine  optimum  feature  sizes  for  symbolic  lines  (Table 
30.4.14  of  the  AWDS  Specification).  This  may  require  viewing 
symbolic  lines  at  different  orientation  angles  on  the  display 
screen. 

1.5  Display  requirements  for  composite  products: 

Digitize  several  of  the  products  in  Section  6.6  of  the  AWDS 
Specification  in  order  to  determine  how  clearly  they  can  be 
displayed  on  a  512  x  512  simulated  pixel  resolution  display 
screen . 

1.6  Study  of  partitioning  of  display  screen  real  estate: 

Given  a  LAWC  display,  examine  how  viewports  could  be  included 
for  product  title,  menus,  error  messages,  and  prompts  without 
seriously  degrading  the  readability  of  the  product  or  the 
amount  of  product  data  displayed. 
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STUDY  AREA  #2  -  GRAPHIC  USER-SYSTEM  INTERFACE 


The  graphic  user-system  interface  study  area  will  be  used  to 
determine  the  most  effective  methods  for  user  interaction  with  the 
AWDS  system.  Graphic  processing  -  especially  interactive  graphic 
processing  -  is  highly  flexible,  and  there  is  an  almost  endless 
variety  of  methods  for  structuring  man-computer  dialogues  -  from 
simple  command  syntaxes  to  sophisticated  menus,  and  from  minimal 
user  hand-holding  to  liberal  use  of  prompting,  default  parameter 
values,  explanatory  messages,  and  error  recovery.  It  is 
particularly  important  to  keep  the  user  in  mind  when  designing  the 
graphic  interface.  Inexperienced  users  prefer  friendly  user- 
forgiving  interfaces,  while  experienced  users  are  more  interested  in 
dialogue  structures  designed  for  speed  of  interaction. 

Study  of  the  user-system  interface  also  includes  determining 
how  to  map  logical  input  functions  to  physical  input  devices.  For 
AWDS,  interaction  with  a  function  or  family  of  functions  could  be 
mapped  1)  to  the  keyboard  only;  2)  to  the  graphic  tablet  only;  or  3) 
to  the  keyboard/tablet  combination.  Different  data  input 
requirements  will  make  the  keyboard/tablet  combination  the  most 
natural  mapping  for  some  AWDS  functions;  however,  this  should  be 
avoided  where  possible  because  ergonomic  considerations  favor  the 
use  of  single  input  device  for  control  of  a  given  function. 

There  are  a  number  of  AWDS  functions  that  make  good  candidate 
topics  for  the  user-system  interface  study  area;  however,  highest 
priority  should  be  given  to  1)  the  composite  product  function;  and 
2)  the  graphic  interaction  function.  These  key  functions  will  have 
heavy  routine  use  in  the  AWDS  system,  and  they  are  functions  that 
embody  important  complementary  aspects  of  graphic  user-system 
interfaces . 

Sample  tasks  in  the  graphic  user-system  interface  study  area 

are: 

2.1  Composite  product  function  interface; 

The  following  are  various  methods  for  initiating  functions 
in  the  horizontal  analysis  product  and  cross  section  product 
composite  function  families.  This  is  not  a  comprehensive 
list,  but  it  is  intended  to  provide  a  variety  of  candidate 
input  methods  from  the  simple  (to  implement)  to  the 
sophisticated.  Each  interface  method  should  be  tested  for 
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one  or  more  of  the  functions  in  one  of  the  composite  product 
families.  It  is  not  necessary  to  implement  the  actual 
functions  that  the  commands  are  supposed  to  invoke;  for  the 
purposes  of  this  user-system  interface  study,  some  minimal 
system  feedback  to  operator  inputs  is  probably  sufficient. 

2.1.  a.  Direct  command/ argument  entry  from  the  alphanumeric 

terminal ; 

This  input  method  involves  a  direct  executive-type 
command  line  entry  with  no  system  prompting.  This 
method  is  the  simplest  to  implement,  but  is  the 
most  difficult  to  use  because  the  operator  must 
fully  understand  the  command  syntax,  order  of 
argument  entry,  and  valid  argument  values. 

2.1. b.  Prompted  entry  (without  defaults)  from  the 

alphanumeric  terminal: 

Upon  input  of  a  command,  the  system  prompts  the 
user  for  entry  of  each  command  argument.  A  value 
for  every  argument  must  be  entered  because  no 
default  value  support  is  included. 

2.1. C.  Prompted  entry  (with  defaults)  from  the 

alphanumeric  terminal: 

This  method  is  the  same  as  2.1.b.,  except  that 
default  values  for  each  argument  are  displayed  with 
each  command  argument  prompt,  and  a  simple  return 
keystroke  will  cause  selection  of  the  default 
value.  The  origination  of  default  values  should 
also  be  investigated.  There  are  a  number  of 
options.  Default  values  could  be:  1)  pre-set  ..  t 
the  time  of  system  initialization;  2)  set  to  the 
argument  value  used  by  the  last  invocation  of  the 
specific  command;  or  3)  set  to  the  last  invocation 
of  any  of  the  commands  in  the  particular  composite 
product  function  family. 

2.1. d.  Entry  using  graphic  display  screen  menus: 

In  their  purest  form,  menus  would  allow  for  full 
interaction  with  composite  product  function 
commands  and  arguments  using  the  graphic 
tablet/terminal  combination.  Arguments  and 
argument  values  should  be  displayed  on  the  graphic 
monitor  and  selected  by  positioning  the  tablet 
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stylus  "over"  the  desired  input  and  pushing  a 
button.  Key  study  topics  for  AWDS  are:  1)  to 
examine  how  the  menus  can  be  designed  for  maximum 
user  support  and  speed  of  input;  and  2)  to 
determine  whether  composite  functions  can  be 
controlled  by  menus  and  the  tablet/stylus 
combination,  or  whether  keyboard  input  is  an 
additional  necessity. 

2.2  The  graphic  interaction  function: 

The  graphic  interaction  function  is  a  family  of  six 
functions;  Add,  Delete,  Modify,  Relocate,  Highlight,  and 
Polygon-Fill.  The  actual  commands  for  initiation  of  these 
functions  could  be  mapped  to  either  the  keyboard  or  the 
graphic  tablet.  Interaction  with  each  function  is  ideally 
suited  to  use  of  the  tablet,  although  selection  of  colors, 
symbols,  and  symbolic  lines  could  be  mapped  to  either  the 
keyboard  or  the  tablet.  For  most  functions,  there  are  a 
variety  of  design  possibilities  that  should  be  explored.  A 
few  of  these  are  given  below  for  each  function. 

2. 2.  a.  Add  (symbol): 

o  Select  color;  draw  symbol  in  freehand  style. 

o  Select  color;  select  symbol  using  keyboard  or 
tablet;  locate  desired  symbol  position;  system 
will  redraw  symbol  at  new  location. 

o  Select  color;  select  symbol  from  menu;  drag 
symbol  to  desired  location. 

2.2. b.  Add  (symbolic  line); 

o  Select  color;  draw  symbolic  line  in  freehand 
style . 

o  Select  color;  select  symbolic  line  using  keyboard 
or  tablet;  draw  a  solid  line  in  freehand  style; 
system  will  replace  the  solid  line  with  the 
desired  symbolic  line. 

2.2. C.  Delete,  highlight,  or  polygon-fill: 

o  Pick  feature  of  interest  using  graphic  tablet; 
system  will  delete  or  highlight  that  feature,  or 
polygon-fill  that  closed  symbolic  line. 
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2.2.d. 


Relocate  (symbol): 


o  Pick  feature;  locate  new  feature  position;  system 
will  redraw  feature  at  new  location. 

o  Pick  feature;  drag  feature  to  new  location. 

2.2. e.  Relocate  (symbolic  line): 

o  Pick  feature  (and  feature  reference  point); 
locate  new  coordinates  of  the  reference  point; 
system  will  redraw  feature  with  the  same 
orientation,  with  the  old  feature  reference  point 
coinciding  with  the  new  coordinates. 

o  Pick  feature  (and  feature  reference  point);  drag 
feature  to  new  location. 

2.2.  f.  Modify  symbolic  line: 

o  Delete  feature;  add  feature. 

o  Pick  feature;  retrace  feature  with  desired 

modifications;  system  will  delete  the  old  copy  of 
the  feature  upon  the  push  of  a  button. 

o  Pick  feature  (and  first  point  on  feature);  pick 
second  point  on  feature;  redraw  (add)  selected 
portion  of  feature;  system  will  delete  old 
portion. 

o  Pick  feature  (and  first  point  on  feature);  redraw 
portion  of  feature  until  old  copy  of  the  feature 
is  re-intersected;  system  will  delete  old 
portion . 
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APPENDIX  B 

CATEGORIZATION  OF  SYSTEM  SPECIFICATION 
MMI  REQUIREMENTS 
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HiBCSDllO  B*ai  BUMUMOV  fUMD 


(G) 

1. 

Perforin  the  graphic  interaction  function  (3. 2 . 1 . 1 . 1 . 2 . 1, 
p.  32). 

(G) 

2. 

Set  up  loop  or  sequence  (3.2. 1.1. 1.2. 1.2,  p.  37). 

(G) 

3. 

Run  the  loop  or  sequence  (3.2. 1.1. 1.2. 1.2.1, 

3. 2. 1.1. 1.2. 1.2. 2,  p.  37). 

(G) 

4. 

Perform  the  zoom  A/roam  function  (3.2. 1.1. 1.2. 1.2, 
pp.  37-38). 

(G) 

5. 

Perform  the  zoom  B  function  (3. 2 . 1 . 1 . 1 . 2 . 1 . 3 ,  pp.  37-38) 

(C) 

6. 

Manage  table  of  reporting  station  display  prioritization 
(3. 2. 1.1. 1.2. 1.4.1,  p.  39). 

(G) 

7. 

Temporarily  override  station  display  prioritization 
(3.2. 1.1. 1.2. 1.4.1,  p.  39). 

(G) 

8. 

Select  UGDF  plot  grid  intersection  spacing 
(3. 2. 1.1. 1.2. 1.4. 2,  p.  39). 

(C) 

9. 

Manage  table  of  airfield  assignments  for  Flight  Control 
Facilities  (FCFs)  (3. 2 . 1 . 1 .2.2,  p.  41). 

(A) 

10. 

Select  product  types  for  Air  Traffic  Control  (ATC)  and 
Flight  Operations  (FO)  displays  (3 . 2 . 1 . 1 . 2 . 2 . 1 . 3  ,  p.  41; 
3.2. 1.1. 2. 2. 2. 3,  p.  42). 

(C) 

11. 

Control  audio-visual  alarms  at  ATC  and  FO  displays 
(3. 2. 1.1. 2. 2. 1.4,  p.  41;  3 . 2 . 1 . 1 . 2 . 2 . 2 .4 ,  p.  42). 

(C) 

12. 

Manage  table  of  graphic  feature  color  assignments 
(3.2.1. 1.3.1,  p.  43). 

(C) 

13. 

Enter  map  data  from  Removable  Magnetic  Storage  Media 
(RMSM)  (longitude-X  and  map  background  entered  manually) 
(3.2. 1.1. 3. 3. 2,  p.  44). 

(A) 

14. 

Print  any  alphanumeric  product  (3. 2. 1.1. 4,  p.  45; 

3. 2. 1.3.1,  p.  57). 

(A) 

15. 

Print  an  alphanumeric  display  (3.2. 1.1.4,  p.  45). 

(A)  16.  Hardcopy  alphanumeric  product  created  using  screen  format 

capabilities  (3. 2. 1.1. 4,  p.  45). 

(G)  17.  Hardcopy  one  to  five  overlaid  graphic  products 

(3.2. 1.1.4,  p.  45;  3. 2. 1.3. 2.  p.  58). 

(A/G)  18.  Manage  command  sequence  (3. 2. 1.1. 5.1,  p.  46). 

(A/G)  19.  Execute  command  sequence  (3.2.1. 1.5.1,  p.  46). 

(A)  20.  Construct/modify  forms/formats  (3.2. 1.1.6,  p.  46). 

(A)  21.  Fill  in  a  form  (create  a  product)  (3. 2. 1.1. 6,  p.  46; 

3.2. 1.8.1,  3.2. 1.8.2,  3. 2. 1.8. 3,  p.  92).  (Also  includes 
Automatic  Responses  to  Queries  (ARQs)  and  Addressed 
Messages.)  (Also  includes  specifying  routing  upon 
completion . ) 

(C)  22.  Manage  list  of  forms/formats  (3.2. 1.1.6,  p.  46). 

(C)  23.  Silence  audible  alert  (3.2. 1.1. 7,  p.  47). 

(C)  24.  Acknowledge  alert  notifications  (3. 2. 1.1. 7,  p.  47). 

(C)  25.  Manage  table  of  products  in  the  data  base  and  their 

retention  criteria  (3.2. 1. 1.8. d,  p.  48;  3.2. 1.6.7, 
p.  90). 

(A)  26.  Generate  a  locally-produced  surface  observation 

(3 . 2 . 1 . 2 . 1 . 1 ,  p.  49).  (Including  display  in  transmission 
format  and  distribute.) 

(A)  27.  Generate  a  locally-produced  upper  air  observation 

(3. 2. 1.2. 1.2,  p.  50). 

(A)  28.  Generate  a  locally-produced  radar  report  (3 . 2 . 1 .2 . 1 . 3, 

p.  50). 

(C)  29.  Manage  table  of  products  for  product  selection 

(3.2. 1.2.3. 1,  p.  51). 

(C)  30.  Manage  METWATCH  criteria  (3.2. 1.2.4,  pp.  52-55). 

(C)  31.  Manage  table  of  products  for  product  alert  (3.2. 1.2.5, 

p.  56). 

(A)  32.  Display  alphanumeric  product  (3. 2. 1.3.1,  pp.  56-57). 
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(G)  33.  Display  overlaid  set  of  one  to  five  graphic  products 

(3.2. 1.3.2,  pp.  57-58). 

(G)  3A.  Display/blank  map  background  topographic  data  (3. 2. 1.3. 2, 

p.  58). 

(G)  35.  Select  parameter  threshold,  phenomena,  and  change 

criteria  for  plot  (3. 2 . 1 .4. 1 . 1 . 3 ,  pp.  62-63). 

(C)  36.  Manage  table  of  reporting  stations  (3.2. 1.4. 1.1.4, 

p.  64). 

(G)  37.  Create  a  surface  selected  parameter  plot  model 

(3.2. 1.4. 1.3. b,  p.  65). 

(G)  38.  Create  a  UGDF  parameter  plot  model  (3 . 2 . 1 .4 . 1 . 3 .d , 

p.  65). 

(C)  39.  Manage  table  of  isopleth  base  values  and  increments 

(3.2. 1.4.3. 1,  p.  67). 

(G)  40.  Perform  horizontal  analysis  composite  product  function 

(3. 2. 1.6. 1.4,  pp.  74-79). 

(G)  41.  Generate  Skew-T,  Log-P  product  (3.2. 1.6.2. 1 ,  pp.  79-82). 

(G)  42.  Perform  cross-section  composite  product  function 

(3.2. 1.6. 2. 2. 5,  pp.  82-88). 

(G)  43.  Generate  continuity  workchart  (3.2. 1.6.3,  p.  88). 

(G)  44.  Generate  extrapolation  product  (3.2. 1.6.4,  p.  89). 

(A)  45.  Display  derived  upper  air  station  parameters 

(3. 2. 1.6. 5. 1,  p.  90). 

(A)  46.  Display  derived  surface  station  parameters  (3 . 2 . 1 . 6 . 5 . 2 , 

p.  90). 

(G)  47.  Delete  a  locally-generated  graphic  product  (3.2. 1.6.7, 

p.  90).  (Explicit  delete  of  any  product  -  3. 2. 1.1. 8, 
p.  48.) 

(A)  48.  Retrieve  station  statistics  by  product  type  (3 . 2 . 1 . 9 . 1 . 1 , 

p.  96). 

(A)  49.  Hardcopy  all  station  statistics  (3 . 2 . 1 . 9 . 1 . 1 ,  p.  96). 


68 


(A)  50.  Reset  all  station  statistics  running  totals  to  zero 

(3. 2. 1.9. 1.1,  p.  96). 

(A)  51.  Transfer  Aircraft  Accident  Investigation  (AAI)  products 

to  Removable  Bulk  Storage  Media  (RMSM)  (3.2. 1.9. 2. 2, 
p.  98). 

(A)  52.  Hardcopy  all  (or  a  subset  of)  AAI  products  from  disk  or 

RMSM  (3.2. 1.9. 2. 2,  p.  98). 

(C)  53.  Annotate  or  add  additional  events  to  event  log 

(3.2. 1.9.3,  p.  98). 

(C)  5A.  Display  event  log  between  selected  start  and  stop  times 

(3.2. 1.9.3. 1,  p.  98). 

(C)  55.  Hardcopy  event  log  between  selected  start  and  stop  times 

(3.2. 1.9.3. 1,  p.  98). 

(A)  56.  Display  complete/partial  monthly  summary  (3.2. 1.9.4, 

p.  99). 

(A)  57.  Hardcopy  complete/partial  monthly  summary  (3.2. 1.9.4, 

p.  99). 

(A)  58.  Purge  old  monthly  summary  (3.2. 1.9.4,  p.  99). 

(A)  59.  Perform  quality  control  (QC)  review  (3.2. 1.9.5,  p.  99). 

(Loop,  at  a  selected  frequency,  through  the  set  of  QC 
products . ) 

(A)  60.  "Correct"  products  during  QC  review  (3.2. 1.9.5,  p.  99). 

(A)  61.  Hardcopy  a  product  that  underwent  QC  review  (3.2. 1.9. 5. 3, 

p.  100). 

(A)  62.  Purge  list  of  products  pending  QC  review  (3. 2. 1.9. 5. 3,  p. 

100). 

(C)  63.  Manage  routing  table  (3.2.1.10.1.1,  p.  101). 

(C)  64.  Initialize  routing  function  from  RMSM  (3.2.1.10.1.1, 

p.  101). 

(A/G)  65.  Manually  override  default  routing  from  the  Observer 
Terminal,  BWS  and  SWO/WWO  (3.2.1.10.1.2,  p.  101). 
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(A/G)  66. 

(A/G)  67. 

(A/G)  68. 
(C)  69. 

(C)  70. 

(C)  71. 

(C)  72. 

(C)  73. 

(A)  74. 

(A)  75. 

(A)  76. 

(A)  77. 

(A)  78. 

(C)  79. 

(C)  80. 

(A/G)  81. 

(A/G)  82. 


Route  a  product  to  a  functional  area  (various  sections, 
pp.  102-105).  (This  may  be  an  implicit  part  of  the 
"Display"  command.) 

Route  to  hardcopy  (3.2.1.10.3.6,  p.  105).  (This  may  be 
an  implicit  part  of  the  alphanumeric  print  and  graphic 
hardcopy  functions . ) 

Route  to  RMSM  (3.2.1.10.3.7,  p.  105). 

Initialize  system  (3.2.1.11.1,  p.  106). 

Checkpoint  system  (3.2.1.11.2,  p.  106). 

Perform  hot  start  recovery  (3.2.1.11.3.1,  p.  106). 

Perform  warm  start  recovery  (3.2.1.11.3.2,  p.  107), 

Perform  cold  start  recovery  (3.2.1.11.3.3,  p.  107). 

Prepare  Notice  to  Airmen  (NOTAM) ,  including  designating 
type  and  disposition  (3.2.1.12.1,  3.2.1.12.1.1,  p.  107; 
3.2.1.12.1.1.1,  3.2.1.12.1.2,  p.  108). 

Transmit/cancel  previously  created  NOTAM  (3.2.1.12.1.1.1, 

p.  108). 

Request  NOTAMs  and  Airfield  Advisories  by  ICAO 
(3.2.1.12.4,  p.  109). 

Hardcopy  NOTAMs  and  Airfield  Advisories  (3.2.1.12.4.2, 

p.  110). 

Prepare  Airfield  Advisory,  including  designating  type 
(3.2.1.13.1.1,  3.2.1.13.1.2,  p.  110). 

Delete  selected  data  for  transmission  after  isolation 
(3.2.1.14.1. ,  p.  111). 

Reassign  terminal  complex  functions  (3.2.1.14.2,  p.  111). 

Display  products  and  list  of  products  affected  by  circuit 
abnormal  conditions  (3.2.1.14.3,  p.  112). 

Hardcopy  products  and  list  of  products  affected  by 
circuit  abnormal  conditions  (3.2.1.14.3,  p.  112). 
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(A/G)  83.  Edit  products  affected  by  circuit  abnormal  conditions 
(3.2.1.14.3,  p.  112). 

(A/G)  84.  Store  edited  product;  purge  abnormally  affected  product 
(3.2.1.14.3,  p.  113). 

(C)  85.  Set  date  and  time  (3.2.1.17,  p.  117). 

(A/G)  86.  Save/retrieve  alphanumeric  or  graphic  "save"  product 
(3.2.1.18.1,  p.  117). 

(A)  87.  Set-aside/retrieve  alphanumeric  "set-aside"  product 

(3.2.1.18.2,  p.  117). 

(A/  88.  Provide  general  prompting  assistance  (3 . 2 . 1 . 1 . 5 . 2 , 

G/C)  p.  46). 

(A/  89.  Display  comprehensive  list  of  commands  and  arguments 

G/C)  (3. 2. 1.1. 5. 2,  p.  46). 

(A/G)  90.  Display  summary  list  of  products  and  related  information 
(3.2. 1.1. 8. c,  p.  48). 

(G)  91.  Provide  operator  initials  for  locally-generated  product 

titling  information  (3.2. 1.7,  p.  90). 

(C)  92.  Display  METWATCH  alerting  conditions  (3.2. 1.2.4,  p.  52). 


KEY 

(A)  -  Alphanumeric  category. 

(G)  -  Graphic  category. 

(C)  -  Control  category. 

(A/G)  -  This  requirement  should  be  treated  in  both  the 

alphanumeric  and  graphic  categories. 

(A/G/C)  -  This  requirement  should  be  treated  in  all  three  areas. 
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APPENDIX  C 

STRAWMAN  HIERARCHY  OF  AWDS  GRAPHIC 
PROCESSING  FUNCTIONS 
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The  graphic  processing  hierarchy  is  depicted  on  11  diagrams, 
each  representing  a  portion  of  the  hierarchy.  On  each  diagram, 
branches  correspond  to  selections  made  at  that  particular  level  in 
the  hierarchy.  Numbered  square  boxes  refer  to  hierarchy  modules 
that  are  described,  along  with  allowable  values,  on  the  pages 
following  each  diagram.  Numbered  circles  at  the  bottom  of  each 
chain  identify  the  hierarchy  module  to  which  control  will  be 
returned  following  execution  of  a  command.'  Diamond-shaped  boxes 
refer  to  notes  describing  special  circumstances  that  must  be 
considered  at  that  level  in  the  hierarchy.  A  companion  set  of 
assumptions  and  notes  appears  at  the  end  of  the  Appendix. 
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HIGHEST  GRAPHIC  HIERARCHY  LEVEL 
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(1.0) 

GRAPHIC  FUNCTION 


HORIZONTAL  COMPOSITE 
SKEW-T,  LOG-P 
FED-  D  X-SECT.  COMP. 

FI' J:  T  ::-SECT.  COMP. 

UGDF:  D  X-SECT.  COMP. 

RUN  LOOP/ SEQUENCE 
EXECUTE  COMMAND  FILE 
START  LOOP  SET-UP/MOD. 

START  COMMAND  FILE  SET -UP /MOD. 
STOP  LOOP  SET-UP/ MOD. 

STOP  COMMAND  FILE  SET-UP/MOD. 
CREATE  SFC.  PLOT  MODEL 
CREATE  UGDF  PLOT  MODEL 


(1.6) 

LOOP/SEQUENCE 

(Available  loops/sequences) 
LOOP  TIME  INTERVAL 


5 

sec 

6 

sec 

7 

sec 

8 

sec 

9 

sec 

10 

sec 

11 

sec 

12 

sec 

13 

sec 

14 

sec 

15 

sec 

16 

sec 

17 

sec 

18 

sec 

19 

sec 

20 

sec 
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(1.7) 

COMMAND  FILE 

(Available  command  files) 
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HORIZONTAI.  ANALYSIS  COMPOSITE  MODULE 


(1.1) 

HORIZONTAL  COMMAND 


DISPLAY 

HARDCOPY 

DELETE 

REMOVE 

SAVE 

RETRIEVE 

PLOT 

ISOPLETH 

STREAMLINE 

EXTRAPOLATION 

ZOOM  A 

ZOOM  B 

GRAPHIC  INTERACTION 
DISPLAY  MAP 
STORE  AND  ROUTE 
CLEAR 
EXIT 

MONITOR 

MONITOR  #1 
MONITOR  #2 


(1.1.2) 

LOCAL  HORIZ.  PRODUCTS 
(Available  products) 


(1.1.3) 

REMOVE 


(Available  numeric 
overlays  comprising 
current  composite) 
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(1.1.4) 


RETRIEVE 

(Available 
horizontal  analysis 
"save"  products) 


(1.1.8) 

ZOOM  A  RATIO 

1:1 

2:1 

4:1 

8:1 

16:1 

EXIT 

MONITOR 

MONITOR  in 
MONITOR  in 
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(1.1.9) 

ZOOM  B  RATIO 


1:1 

2:1 

4:1 

8:1 

16:1 

EXIT 

MONITOR 

MONITOR  n 
MONITOR  #2 

STAT.  DISP.  PRIORITY 


STANDARD 

OVERRIDE 

UGDF  DISP.  DENSITY 


HIGHEST  DISPLAYABLE 
EVERY  OTHER  POINT 
EVERY  4TH  POINT 
EVERY  8TH  POINT 
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MAP  BACKGROUND 


UWC  #1 
LAWC  #2 
LAWC  #3 

SUBW.  N.  CENT.  U.S. 
SUBW.  S.  CENT.  U.S. 
SUBW.  EAST  U.S. 
SUBW.  N.E.  U.S. 
SUBW.  S.E.  U.S. 
SUBW.  N.E.  ATLANTIC 
TROP.  W.  PACIFIC 
TROP.  E.  PACIFIC 
TROP.  W.  HEMISPHERE 
TROP.  ATLANTIC 
TROP.  AFRICA 
REG.  WINDOW  CONUS 
REG.  WINDOW  E.  U.S. 
REG.  WINDOW  N.  U.S. 
CONT.  N.  AMERICA 
CONT.  ATLANTIC 
CONT.  N.E.  PACIFIC 
N.  HEMISPHERE  U.S. 
S.  HEMISPHERE 


(1.1.11) 

ROUTING 

(Available  functional 
areas,  including  hardcopy) 


i 


i  i 

i! 


IA-C9.796 


HORIZONTAL  ANALYSIS  DISPLAY  MODULE 


BRANCHES 

A  -  VECTOR  GRAPHIC 
B  -  SATELLITE 

C  -  PACKED  PIXEL;  UNPACKED  PIXEL 
D  -  LOCALLY  GENERATED 
E  -  SINGLE-LEVEL  PARAMETER 
F  -  MULTIPLE-LEVEL  PARAMETER  OR  N/A 
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(1.1.1) 

DATA  INDICATOR 


VECTOR  GRAPHIC 
SATELLITE 
PACKED  PIXEL 
UNPACKED  PIXEL 
LOCALLY -GENERATED 


(1.1. 1.1) 

DATA  DESIGNATOR 


WEATHER  SUMMARY 
CONVECTIVE  ANALYSIS 
THICKNESS  ANALYSIS 
LOCAL  WIND  ANALYSIS 
TROP.  WEATHER  SUMMARY 
RADAR  ANALYSIS 
lAC  U/A  ANALYSIS 
WIND  ANALYSIS 
ARFOR 

U/A  &  TEMP.  FORECAST 
EXTENDED  FORECASTS 
OPERATIONAL  FORECAST 
lAC-IAC  FLEET  SURFACE 
lAC  U/A 
MISCELLANEOUS 
SWELL 

SEA  SURFACE  TEMP. 

MIL.  WX.  WARNING 
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(1.1. 1.1.1,  1.1. 1.3.1) 
GEOG.  DESIGNATOR 


SUBW.  N.  CENT.  U.S. 
SUBW.  S.  CENT.  U.S. 
SUBW.  E.  U.S. 

SUBW.  N.E.  U.S. 
SUBW.  S.E.  U.S. 
SUBW.  N.E.  ATLANTIC 
TROP.  W.  PACIFIC 
TROP.  E.  PACIFIC 
TROP.  W.  HEMISPHERE 
TROP.  ATLANTIC 
TROP.  AFRICA 
REG.  WINDOW  CONUS 
REG.  WINDOW  E.  U.S. 
REG.  WINDOW  N.  U.S. 
CONT.  N.  AMERICA 
CONT.  ATLANTIC 
CONT.  N.E.  PACIFIC 
N.  HEMISPHERE  U.S, 
S.  HEMISPHERE  U.S. 
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(1.1. 1.1. 1.1) 


BASE  TIME/PART  » 


0  - 

PART 

1 

6  - 

PART 

1 

12  - 

PART 

1 

18  - 

PART 

1 

0  - 

PART 

2 

6  - 

PART 

2 

12  - 

PART 

2 

18  - 

PART 

2 

0  - 

PART 

3 

6  - 

PART 

3 

12  - 

PART 

3 

18  - 

PART 

3 

0  - 

PART 

4 

6  - 

PART 

4 

12  - 

PART 

4 

18  - 

PART 

4 

JAY 

TODAY 

YESTERDAY 

DAY 

BEFORE 

j6 


(1.1. 1.1. 1.1.1) 

ATM.  LEVEL 


SURFACE 
1000  mb 
850  mb 
700  mb 
600  mb 
500  mb 
400  mb 
300  mb 
250  mb 
200  mb 
150  mb 
100  mb 
50  mb 

TROPOPAUSE 
M/L  THUNDERSTORMS 
M/L  CLOUDS  &  WX. 
M/L  TURB.  &  ICING 
M/L  WINDS  &  JET 
M/L  SURF.  FEATURES 
M/L  WX.  DEPICTION 
M/L  UNSPECIFIED 
N/A 
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(1.1. 1.1. 1.1. 1.1) 

PARAMETER 

MULTIPLE  PARAMETER 
TOTAL  CLOUD  AMOUNT 
CLOUD  BASE 
CLOUD  TOP 
D-VALUE 

EQUIV.  POT.  TEMP. 

STREAM  FUNCTION 

GEOPOTENTIAL  HEIGHT 

HIGH  CLOUD  AMOUNT 

DIVERGENCE 

VORTICITY 

STREAMLINES 

LOW  CLOUD  AMOUNT 

MIDDLE  CLOUD  AMOUNT 

DEWPOINT  DEPRESSION 

OMEGA 

PRESSURE 

QUANT.  PRECIP.  FORECAST 
BND.  LAY.  D.P.  DEP. 
SWEAT 

TEMPERATURE 
U-COMPONENT 
V -COMPONENT 
PRECIPITABLE  WATER 
PRIM.  PRES.  WEATH. 

SEC.  PRES.  WEATH. 

TERT.  PRES.  WEATH. 
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(1.1. 1.1. 1.1. 1.1. I.  1.1. 1.1. 1.1. 1.2) 

FORECAST  HOURS /DAYS 


0  hours 
6  hours 
12  hours 
18  hours 
30  hours 
36  hours 

1  day 

2  days 

3  days 
A  days 

5  days 

6  days 

7  days 

8  days 

9  days 
10  days 


(1.1. 1.2,  1.1. 1.3) 

DATA  DESIGNATOR 

SATELLITE  ANALYSIS 
SYN.  INT.  SAT.  CLOUD  DAT. 
SATELLITE  IMAGERY 


(1.1. 1.2.1) 

GEOG.  DESIGNATOR 

SUBW.  N.  CENT.  U.S. 
SUBW.  S.  CENT.  U.S. 
SUBW.  E.  U.S. 

SUBW.  N.E.  U.S. 
SUBW.  S.E.  U.S. 
SUBW.  N.E.  ATLANTIC 
REG.  WINDOW  CONUS 
REG.  WINDOW  E.  U.S. 
REG.  WINDOW  N.  U.S. 
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AD-A146  033  USE  OF  PROTOTYPING  FOR  MAN-MACHINE  INTERFACE 

REQUIREMENTS  DEFINITION  ON  T..(U)  MITRE  CORP  BEDFORD  MA 
C  W  BENKLEY  AUG  64  MTR-9234  ESO-TR-84- 178 
UNCLASSIFIED  F 19628-84-C-0001  F/G  9/2 


MfCROCOPY  RESOLUTION  TEST  CHART 

national  BUfttAU  Of  SlANpARDS  l%i  A 


(1.1. 1.2. 1.1,  1.1. 1.3. 1.1.1) 
VALID  TIME 


(Available  times) 


(1.1. 1.3. 1.1) 
ATM.  LEVEL 


SURFACE 
850  mb 
700  mb 
600  mb 
500  mb 
AOO  mb 
300  mb 
250  mb 
200  mb 
150  mb 
100  mb 
50  mb 


(1.1. 1.4) 

LOCAL  HORIZ.  PRODUCTS 


(Available  products) 
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(1.1.5) 


DATA  INDICATORS 


FORMATTED  BINARY 
PKD.  1/2  MESH 
PKD.  1/8  MESH 
PKD.  1/64  MESH 
UNPKD.  WHOLE  MESH 
UNPKD.  1/2  MESH 
UNPKD.  1/8  MESH 
UNPKD.  1/64  MESH 


(1. 1.5.1) 

DATA  DESIGNATOR 


HOURLY  AND  1/2  HR. 

SPECIALS 

RAW  IN 


(1.1.5. 1.1) 

SFC  PLOT  MODEL 

(Available  surface  plot 
models;  help  information 
could  identify  parameters 
included) 


(1.1. 5. 1.1.1,  1.1.5. 1.2.1) 
VALID  TIMES 
(Available  times) 
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(1.1.5. 1.1. 1.1) 
SELECTION  CRITERIA 
NONE 

THRESHOLD  SELECTION 
PHENOMENA  SELECTION 
CHANGE  SELECTION 


(1.1.5. 1.1. 1.1.1,  1.1.5. 1.2. 1.1.1, 
1. 1.5.2. 1.1. 1.1. 1.1) 

DATA  OVERRIDE 


DATA  OVERRIDE 
NO  OVERRIDE 


(1.1. 5. 1.2) 

ATMOS.  LEVEL 


1000  mb 
850  mb 
700  mb 
500  mb 
400  mb 
300  mb 
200  mb 
150  mb 
100  mb 
50  mb 
30  mb 
10  mb 


(1.1.5. 1.2. 1.1) 
SELECTION  CRITERIA 


NONE 

THRESHOLD  SELECTION 
CHANGE  SELECTION 
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DATA  DESIGNATOR 


WEATHER  SUMMARY 
CONVECTIVE  ANALYSIS 
GRID.  T.  AND  D.P.  DEP. 
THICKNESS  ANALYSIS 
LOCAL  WIND  ANALYSIS 
SATELLITE  ANALYSIS 
lAC  U/A  ANALYSIS 
VERT.  MOTION  ANALYSIS 
WIND  ANALYSIS 
MISCELLANEOUS 
ARFOR 

U/A  WIND  AND  T.  FORECAST 
EXTENDED  FORECASTS 
GRID  POINT  FORECASTS 
OPERATIONAL  FORECASTS 
lAC  UPPER  AIR 
VERT.  MOTION  PROGNOSIS 
SEA  SURFACE  TEMPERATURE 
SYN.  INT.  OF  SAT.  CL.  DATA 


(1. 1.5.2. 1) 

GEOGRAPHIC  DESIGNATOR 


REG.  WINDOW  CONUS 
REG.  WINDOW  E.  U.S. 
REG.  WINDOW  N.  U.S. 


(1. 1.5.2. 1.1) 
BASE  TIME/PART  iit 


0  -  PART  1 
6  -  PART  1 
12  -  PART  1 
18  -  PART  1 
0  -  PART  2 
6  -  PART  2 
12  -  PART  2 
18  -  PART  2 
0  -  PART  3 
6  -  PART  3 
12  -  PART  3 
18  -  PART  3 
0  -  PART  4 
6  -  PART  4 
12  -  PART  4 
18  -  PART  4 

DAY 

TODAY 
YESTERDAY 
DAY  BEFORE 


(1. 1.5.2. 1.1.1) 
ATMOSPHERIC  LEVEL 


1000  mb 
850  mb 
700  mb 
500  mb 
300  mb 
200  mb 
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(1. 1.5.2. 1.1. 1.1) 


FORECAST  HOURS/DAYS 

0  hours 
6  hours 
12  hours 
18  hours 
30  hours 
36  hours 

1  day 

2  days 

3  days 

4  days 

5  days 

6  days 

7  days 

8  days 

9  days 
10  days 


(1. 1.5.2. 1.1. 1.1.1) 
UGDF  PLOT  MODEL 


(Available  UGDF  plot 
models;  help  information 
could  identify  parameters 
included) 
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ISOPLETH  MODULE 


■  -  ENTER  ISOPLETH  LEVELS 
b  -  ENTER  DATA  OVERRIDE  INFORMATION 


97 


DATA  INDICATORS 


FORMATTED  BINARY 
PKD.  1/2  MESH 
PKD.  1/8  MESH 
PKD.  1/64  MESH 
UNPKD.  WHOLE  MESH 
UNPKD.  1/2  MESH 
UNPKD.  1/8  MESH 
UNPKD.  1/64  MESH 


(1. 1.6.1) 

DATA  DESIGNATOR 

HOURLY  AND  1/2  HR. 

SPECIALS 

RAWIN 


(1.1.6. 1.1) 

SURFACE  PARAMETER 


ALTIMETER  SETTING 

BARO.  TENDENCY 

DEWPOINT  TEMPERATURE 

SEA  LEVEL  PRESSURE 

TEMPERATURE 

VISIBILITY 

WIND  SPEED 

RELATIVE  HUMIDITY 

ADVECTED  FIELD 

ADVECTION 

ADD 

SUBTRACT 
U -COMPONENT 
V-COMPONENT 


(1.1.6. 1.1.1,  1.1. 6. 1.2.1) 

VALID  TIME 


(Available  times) 


(1.1. 6. 1.1. 1.1,  1.1. 6. 1.2. 1.1.1, 
1. 1.6.2. 1.1. 1.1. 1.1) 

ISOPLETH  LEVELS 


DEFAULT 

(Help  Information  could 
identify  default  bases 
and  increments) 

NEW  VALUES 


(1.1. 6. 1.1. 1.1.1,  1.1. 6. 1.2. 1.1. 1.1, 
1. 1.6.2. 1.1. 1.1. 1.1.1) 


DATA  OVERRIDE 


DATA  OVERRIDE 
NO  OVERRIDE 


(1.1.6. 1.2) 

U/A  PARAMETER 


DEWPOINT  DEPRESSION 

GEOPOTENTIAL  HEIGHT 

TEMPERATURE 

WIND  SPEED 

RELATIVE  .lUMIDITY 

D-VALUES 

ADVECTED  FIELD 

ADVECTION 

ADD 

SUBTRACT 

U-COMPONENT 

V-COMPONENT 


1 

■ 


1 
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(1.1.6. 1.2. 1.1) 

ATMOSPHERIC  LEVEL 


1000  mb 
850  mb 
700  mb 
500  mb 
400  mb 
300  mb 
200  mb 
150  mb 
100  mb 
50  mb 
30  mb 
10  mb 


(1. 1.6.2) 

DATA  DESIGNATOR 


WEATHER  SUMMARY 
CONVECTIVE  ANALYSIS 
GRID.  T.  AND  D.P.  DEP. 
THICKNESS  ANALYSIS 
LOCAL  WIND  ANALYSIS 
SATELLITE  ANALYSIS 
lAC  U/A  ANALYSIS 
VERT.  MOTION  ANALYSIS 
WIND  ANALYSIS 
MISCELLANEOUS 
ARFOR 

U/A  WIND  AND  T.  FORECAST 
EXTENDED  FORECASTS 
GRID  POINT  FORECASTS 
OPERATIONAL  FORECASTS 
lAC  UPPER  AIR 
VERT.  MOTION  PROGNOSIS 
SEA  SURFACE  TEMPERATURE 
SYN.  INT.  OF  SAT.  CL.  DATA 


100 


(1. 1.6.2. 1) 

GEOGRAPHIC  DESIGNATOR 


REG.  WINDOW  CONUS 
REG.  WINDOW  E.  U.S. 
REG.  WINDOW  N.  U.S. 


(1. 1.6.2. 1.1) 

UGDF  MNEMONIC 
D-VALUE 

EQUIV.  POT.  TEMP. 

STREAM  FUNCTION 
GEOPOTENTIAL  HEIGHT 
DIVERGENCE 
VORTICITY 

DEWPOINT  DEPRESSION 
OMEGA 

QUANT.  PRECIP.  FORECAST 
BOUND.  LAY.  DEW.  DEP. 
SWEAT 

TEMPERATURE 
U-COMPONENT 
V-COMPONENT 
RELATIVE  HUMIDITY 
WIND  SPEED 
ADVECTED  FIELD 
ADVECTION 
ADD 

SUBTRACT 
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(1. 1.6.2. 1.1.1) 


BASE  TIME/PART  # 


0  - 

PART 

1 

6  - 

PART 

1 

12  - 

PART 

1 

18  - 

PART 

1 

0  - 

PART 

2 

6  - 

PART 

2 

12  - 

PART 

2 

18  - 

PART 

2 

0  - 

PART 

3 

6  - 

PART 

3 

12  - 

PART 

3 

18  - 

PART 

3 

0  - 

PART 

4 

6  - 

PART 

4 

12  - 

PART 

4 

18  - 

PART 

4 

DAY 

TODAY 
YESTERDAY 
DAY  BEFORE 

(1.1. 6. 2. 1.1. 1.1) 

ATMOSPHERIC  LEVEL 


1000  mb 
850  mb 
700  mb 
500  mb 
300  mb 
200  mb 
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(1. 1.6.2. 1.1. 1.1.1) 


FORECAST  HOURS/DAYS 

0  hours 
6  hours 
12  hours 
18  hours 
30  hours 
36  hours 

1  day 

2  days 

3  days 

4  days 

5  days 

6  days 

7  days 

8  days 

9  days 
10  days 
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STREAMLINE  MODULE 
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(1.1.7) 

DATA  INDICATORS 


FORMATTED  BINARY 
PKD.  1/2  MESH 
PKD.  J/8  MESH 
PKD.  1/64  MESH 
UNPKD.  WHOLE  MESH 
UNPKD.  1/2  MESH 
UNPKD.  1/8  MESH 
UNPKD.  1/64  MESH 


(1.1.7. 1) 

DATA  DESIGNATOR 

HOURLY  AND  1/2  HR. 

SPECIALS 

RAWIN 


(1.1. 7. 1.1,  1.1.7. 1.2.1) 
VALID  TIME 
(Available  times) 


(1.1. 7. 1.1.1,  1.1. 7. 1.2. 1.1, 

1.1. 7. 2. 1.1. 1.1.1) 

DATA  OVERRIDE 

DATA  OVERRIDE 
NO  OVERRIDE 
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(1.1.7. 1.2) 


i 

ATMOSPHERIC  LEVEL 


1000 

mb 

850 

mb 

700 

mb 

500 

mb 

400 

mb 

300 

mb 

200 

mb 

150 

mb 

1 

♦ 

100 

mb 

50 

mb 

30 

mb 

10 

mb 

(1. 1.7.2) 

DATA  DESIGNATOR 

WEATHER  SUMMARY 
CONVECTIVE  ANALYSIS 
GRID.  T.  AND  D.P.  DEP. 
THICKNESS  ANALYSIS 
LOCAL  WIND  ANALYSIS 
SATELLITE  ANALYSIS 
lAC  U/A  ANALYSIS 
VERT.  MOTION  ANALYSIS 
WIND  ANALYSIS 
MISCELLANEOUS 
ARFOR 

U/A  WIND  AND  T.  FORECAST 
EXTENDED  FORECASTS 
GRID  POINT  FORECASTS 
OPERATIONAL  FORECASTS 
lAC  UPPER  AIR 
VERT.  MOTION  PROGNOSIS 
SEA  SURFACE  TEMPERATURE 
SYN.  INT.  OF  SAT.  CL.  DATA 
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(1.1. 7. 2.1) 

GEOGRAPHIC  DESIGNATOR 


REG.  WINDOW  CONUS 
REG.  WINDOW  E.  U.S. 
REG.  WINDOW  N.  U.S. 


(1.1. 7. 2. 1.1) 

BASE  TIME/PART  # 


0 

- 

PART 

1 

6 

- 

PART 

1 

12 

- 

PART 

1 

18 

- 

PART 

1 

0 

- 

PART 

2 

6 

- 

PART 

2 

12 

- 

PART 

2 

18 

- 

PART 

2 

0 

- 

PART 

3 

6 

- 

PART 

3 

12 

- 

PART 

3 

18 

- 

PART 

3 

0 

- 

PART 

4 

6 

- 

PART 

4 

12 

- 

PART 

4 

18 

- 

PART 

4 

DAY 

TODAY 
YESTERDAY 
DAY  BEFORE 
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(1.1. 7. 2. 1.1.1) 

ATMOSPHERIC  LEVEL 


1000  mb 
850  mb 
700  mb 
500  mb 
300  mb 
200  mb 


(1.1. 7. 2. 1.1. 1.1) 

FORECAST  HOURS /DAYS 


0  hours 
6  hours 
12  hours 
18  hours 
30  hours 
36  hours 

1  day 

2  days 

3  days 

4  days 

5  days 

6  days 

7  days 

8  days 

9  days 
10  days 
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(1.2) 

SKEW-T  COMMAND 


DISPLAY 

HARDCOPY 

DELETE 

SAVE 

RETRIEVE 
GENERATE 
ZOOM  A 
ZOOM  B 

GRAPHIC  INTERACTION 
STORE  AND  ROUTE 
CLEAR 
EXIT 

MONITOR 


MONITOR  #1 
MONITOR  n 


(1.2.1) 

SKEW-T  PRODUCTS 
(Available  products) 


(1.2.2) 

RETRIEVE 


(Available 
Skew-T,  Log-P 
"save"  products) 


(1.2.3) 
STATION 
(Up  to  100) 
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(1.2.3. 1) 

#  OF  PREVIOUS  TIMES 

0 

1 

2 


(1.2.3. 1.1) 

DATA  OVERRIDE 

DATA  OVERRIDE 
NO  OVERRIDE 


(1.2. A) 

ZOOM  A  RATIO 


1:1 
2:1 
4: 1 
8:1 
16:1 
EXIT 

MONITOR 

MONITOR  in 
MONITOR  #2 


ill 


(1.2.5) 

ZOOM  B  RATIO 


1:1 

2:1 

4:1 

8:1 

16:1 

EXIT 

MONITOR 

MONITOR  #1 
MONITOR  in 


(1.2.6) 

ROUTING 


(Available  functional 
areas,  including  hardcopy) 
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(1.3) 

CROSS  SECTION  COMMAND 


DISPLAY 

HARDCOPY 

DELETE 

REMOVE 

SAVE 

RETRIEVE 
CONTOUR 
SPECIFY  PATH 
PLOT 
ZOOM  A 
ZOOM  B 

GRAPHIC  INTERACTION 
STORE  AND  ROUTE 
CLEAR 
EXIT 

MONITOR 


MONITOR  in 
MONITOR  in 


(1.3.1) 

CROSS  SECTION  PRODUCTS 
(Available  products) 


(1.3.2) 

REMOVE 


(Available  numeric 
overlays  comprising 
current  composite) 
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RETRIEVE 


(Available 

"save"  products  valid 
for  cross  section  type 
and  path) 


(1.3.4) 

CONTOUR 


POTENTIAL  TEMP. 
EQUIV.  POT.  TEMP. 
D-VALUES 

VERT.  WIND  SHEAR 
RELATIVE  HUMIDITY 
MIXING  RATIO 
TEMPERATURE 
DEWPOINT  DEPRESSION 
WIND  SPEED 


(1.3.4. 1) 
CONTOUR  LEVELS 


DEFAULT  <par.  nanie> 
(Help  information  could 
identify  default  bases, 
increments,  and  units) 
NEW  VALUES 


1 
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(1.3.4. 1.1,  1.3.6) 

DATA  OVERRIDE 

DATA  OVERRIDE 
NO  OVERRIDE 


(1.3.5) 
STATIONS 
(Up  to  100) 
VALID  TIME 


0  hours 
6  hours 
12  hours 
18  hours 

DAY 

TODAY 
YESTERDAY 
DAY  BEFORE 


(1.3.7) 

ZOOM  A  RATIO 


1:1 

2:1 

4:1 

8:1 

16:1 

EXIT 

MONITOR 

MONITOR  in 
MONITOR  #2 
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(1.3.8) 


ZOOM  B  RATIO 


1:1 

2:1 

4:1 

8:1 

16:1 

EXIT 

MONITOR 

MONITOR  #1 
MONITOR  #2 


(1.3.9) 

ROUTING 


(Available  functional  areas, 
including  hardcopy) 
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FSO:  TIME  CROSS  SECTION  MODULE 
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(l.A) 

CROSS  SECTION  COMMAND 


DISPLAY 

HARDCOPY 

DELETE 

REMOVE 

SAVE 

RETRIEVE 
CONTOUR 
SPECIFY  PATH 
PLOT 
ZOOM  A 
ZOOM  B 

GRAPHIC  INTERACTION 
STORE  AND  ROUTE 
CLEAR 
EXIT 

MONITOR 

MONITOR  #1 
MONITOR  n 


(l.A.l) 

CROSS  SECTION  PRODUCTS 
(Available  products) 


(1.A.2) 

REMOVE 


(Available  numeric 
overlays  comprising 
current  composite) 
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(1.4.3) 


RETRIEVE 


(Available  "save"  products  valid 
for  cross  section  type  and  path) 


(1.4.4)  { 

CONTOUR  I 

POTENTIAL  TEMP.  i 
EQUIV.  POT.  TEMP.  < 
D -VALUES 

VERT.  WIND  SHEAR  I 
RELATIVE  HUMIDITY  i 
MIXING  RATIO  j 
TEMPERATURE  , 
DEWPOINT  DEPRESSION  ! 
WIND  SPEED 


(1.4.4. 1) 
CONTOUR  LEVELS 


DEFAULT  <par .  natne> 
(help  information  could 
identify  default  bases, 
increments,  and  units) 
NEW  VALUES 
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(1.4.4. 1.1,  1.4.6) 

DATA  OVERRIDE 

DATA  OVERRIDE 
NO  OVERRIDE 

(1.4.5) 

STATION 

(Up  to  100) 

//  OF  PREVIOUS  TIMES 

1 

2 

3 


(1.4.7) 

ZOOM  A  RATIO 


1:1 
2:1 
4:1 
8: 1 
16:1 
EXIT 

MONITOR 


MONITOR  //I 
MONITOR  in 


(1.4.8) 

ZOOM  B  RATIO 


1:1 

2:1 

4:1 

8:1 

16:1 

EXIT 

MONITOR 

MONITOR  in 
MONITOR  in 


(1.4.9) 

ROUTING 


(Available  functional  areas, 
including  hardcopy) 
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UGOF:  DISTANCE  CROSS  SECTION  MODULE 


(1.5) 

CROSS  SECTION  COMMAND 


DISPLAY 

HARDCOPY 

DELETE 

REMOVE 

SAVE 

RETRIEVE 
CONTOUR 
SPECIFY  PATH 
ZOOM  A 
ZOOM  B 

GRAPHIC  INTERACTION 
STORE  AND  ROUTE 
CLEAR 
EXIT 

MONITOR 


MONITOR  n 
MONITOR  #2 
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(1.5.1) 

CROSS  SECTION  PRODUCTS 


(Available  products) 


(1.5.2) 

REMOVE 


(Available  numeric 
overlays  comprising 
current  composite) 


(1.5.3) 

RETRIEVE 


(Available  "save"  products 
valid  for  cross  section  type 
and  path) 


(1.5.4) 

CONTOUR 

POTENTIAL  TEMP. 
EQUIV.  POT.  TEMP. 
D-VALUES 

VERT.  WIND  SHEAR 
RELATIVE  HUMIDITY 
MIXING  RATIO 
TEMPERATURE 
DEWPOINT  DEPRESSION 
WIND  SPEED 
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(1.5.4. 1) 


CONTOUR  LEVELS 

DEFAULT  <par.  naine> 

(help  information  could 
identify  bar.es,  increments, 
and  units) 

NEW  VALUES 


(1.5. 4. 2) 

DATA  OVERRIDE 

DATA  OVERRIDE 
NO  OVERRIDE 
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(1.5.5) 

REGIONAL  WINDOW 


CONUS 
EAST  U.S. 
NORTH  U.S. 

MESH  SIZE 


WHOLE 
HALF 
EIGHTH 
SIXTY -FOURTH 


(1.5.5. 1) 

DATA  DESIGNATOR 


WEATHER  SUMMARY 
CONVECTIVE  ANALYSIS 
GRID  T.  AND  D.P.  DEP 
THICKNESS  ANALYSIS 
LOCAL  WIND  ANALYSIS 
SATELLITE  ANALYSIS 
lAC  U/A  ANALYSIS 
VERTICAL  MOTION  ANALYSIS 
WIND  ANALYSIS 
MISCELLANEOUS 
ARFOR 

U/A  WIND  AND  T.  FORECAST 
EXTENDED  FORECASTS 
GRID  POINT  FORECASTS 
OPERATIONAL  FORECASTS 
lAC  UPPER  AIR 
VERTICAL  MOTION  PROGNOSIS 
SEA  SURFACE  TEMPERATURE 
SYN.  INT.  OF  SAT.  CL.  DATA 
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(1.5.5. 1.1) 
BASE  TIME/PART 


0  - 

PART 

1 

6  - 

PART 

1 

12  - 

PART 

1 

18  - 

PART 

1 

0  - 

PART 

2 

6  - 

PART 

2 

12  - 

PART 

2 

18  - 

PART 

2 

0  - 

PART 

3 

6  - 

PART 

3 

12  - 

PART 

3 

18  - 

PART 

3 

0  - 

PART 

4 

6  - 

PART 

4 

12  - 

PART 

4 

18  - 

PART 

4 

DAY 

TODAY 
YESTERDAY 
DAY  BEFORE 

(1.5.5. 1.1.1) 
FORECAST  HOURS/DAYS 

0  hours 

6  hours 
12  hours 
18  hours 
30  hours 
36  hours 

1  day 

2  days 

3  days 

4  days 

5  days 

6  days 

7  days 

8  days 

9  days 
10  days 
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(1.5.6) 


ZOOM  A  RATIO 

1:1 

2:1 

4:1 

8:1 

16:1 

EXIT 

MONITOR 

MONITOR  in 
MONITOR  in 


(1.5.7) 

ZOOM  B  RATIO 

1:1 

2:1 

4:1 

8:1 

16:1 

EXIT 

MONITOR 

MONITOR  in 
MONITOR  in 


(1.5.8) 

ROUTING 

(Available  functional  areas. 
Including  hardcopy) 
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GRAPHIC  INTERACTION  MODULE 


(2.0) 

GRAPHIC  INTERACTION 


ADD  SYMBOL 
ADD  SYMBOLIC  LINE 
ADD  CHARACTER 
ADD  TEXT 
DELETE  FEATURE 
HIGHLIGHT  FEATURE 
RELOCATE  FEATURE 
MODIFY  FEATURE 
POLYGON  FILL 
EXIT 

MONITOR 


MONITOR  #1 
MONITOR  #2 


(2.1) 

ADD  SYMBOL 
(Specify  symbol) 


(2.2) 

ADD  SYMBOLIC  LINE 


(Specify  symbolic  line) 


(2.3) 

ADD  CHARACTER 

(Specify  character, 
color,  character  size, 
and  line  width) 
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(2.4) 

ADD  TEXT 

(Input  text  string; 
specify  color, 
character  size, 
and  line  width) 
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(3.0) 

ADVECTION  INTERVAL 

1  hour 

2  hours 

3  hours 

4  hours 

5  hours 

6  hours 

7  hours 

8  hours 

9  hours 

10  hours 

11  hours 

12  hours 
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ASSUMPTIONS  AND  NOTES 


General 

(1)  The  system  should  not  permit  the  operator  to  store  an  exact 
copy  of  an  externally-generated  product  (i.e.,  an  externally- 
generated  product  that  has  not  been  interacted  with,  or 
overlayed  with,  another  product). 

(2)  The  STORE  option  could  either  return  the  user  to  the  top  of 
the  hierarchy  (module  1.0)  or  to  the  appropriate  place  in  the 
next  level  in  the  hierarchy  (e.g. ,  module  1.1  or  1.2).  There 
are  probably  advantages  to  each  implementation,  but  one 
consistent  choice  should  be  adopted. 

(3)  Hierarchy  module  1.1.10  lists  22  map  backgrounds  that  might  be 
appropriate  for  a  Base  Weather  Station  (BWS)  in  the 
Northeastern  United  States.  The  hierarchy  module  for  the 
product  geographic  designator  (e.g.,  1.1. 1.1.1,  1.1. 1.3.1, 
etc.)  lists  only  those  map  backgrounds  that  are  appropriate 
for  the  given  product  type.  For  Uniform  Gridded  Data  Field 
(UGDF)  products,  only  regional  window  geographic  designators 
apply.  For  satellite  products,  only  regional  window  and 
satellite  subwindow  geographic  designators  apply.  For  vector 
graphic  and  pixel  products,  satellite  subwindow  and  Local  Area 
Workchart  (LAWC)  geographic  designators  do  not  apply. 

(4)  In  order  to  obviate  the  need  to  remove  and  totally  regenerate 
products  when  bad  data  is  encountered,  the  data  override 
option  is  placed  at  the  bottom  of  each  appropriate  branch  in 
the  hierarchy,  and  cannot  be  invoked  until  the  product  is 
displayed.  At  that  time,  noting  bad  data,  execution  of  the 
data  override  option  would  cause  the  system  to  remove  the 
erroneous  product  from  the  display,  and  regenerate  a  corrected 
copy.  Actual  specification  of  override  information  could  be 
as  follows; 

a)  Allow  the  user  to  specify  the  parameter  of  interest 
from  the  appropriate  parameter  hierarchy  module 
(surface  Formatted  Binary  Data  (FBD)  parameter,  upper 
air  FBD  parameter,  or  UGDF  parameter); 

b)  Display  the  appropriate  data  (station  parameters  or 
UGDF  grid  point  parameters)  at  the  proper  map  or  cross 
section  path  coordinates  and  allow  the  user  to  pick  the 
bad  value; 
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c)  Enter  the  new  (override)  parameter  value  as  a  text 
string;  and 

d)  Repeat  this  procedure  as  many  times  as  necessary  to 
override  all  bad  data. 

5)  According  to  Specification  Section  3.2.1.16.2,  an  average  of 
90A  products  components  will  be  locally-generated  every  24 
hours.  This  corresponds  to  generating  one  graphic  product 
component  every  one  minute  and  35  seconds ,  a  rate  which 
appears  to  be  excessive  even  for  an  AWDS  with  multiple  Staff 
Weather  Officer/Wing  Weather  Officer  (SWO/WWO)  functional 
areas.  Nevertheless,  the  magnitude  of  this  number  suggests 
that  it  may  be  difficult  to  keep  track  of  locally-generated 
products  in  the  system,  especially  in  view  of  the  fact  that 
locally-generated  product  names  are  selected  by  the  operator. 

A  hierarchy  of  locally-generated  product  types  might  have  to 
be  enforced  in  order  to  facilitate  retrieval. 

(6)  When  more  than  one  "menu"  appears  for  a  given  hierarchy 
module,  a  menu-driven  implementation  could  accommodate  the 
multiple  menus  on  a  single  menu  page.  For  other 
implementations,  however,  additional  hierarchical  levels  are 
needed. 

(7)  It  is  assumed  that  product  retention  criteria  is  based  upon 
product  categories,  not  individual  products  themselves.  This 
function  is  included  in  the  control  category. 

(8)  The  requirements  for  manual  routing  of  graphic  (and,  probably 
alphanumeric)  products  within  AWDS  are  confusing;  all  graphic 
products  should  already  be  available  at  all  functional  areas 
that  support  graphic  processing.  For  the  strawman  hierarchy, 
it  is  assumed  that  manual  routing  of  externally-generated 
products  is  not  needed.  Requirements  for  routing  of  locally- 
generated  products  are  interpreted  as  a  means  by  which  the 
operator,  after  storing  a  product,  can  specify  related  routing 
information  -  whatever  its  use. 

(9)  Ideally,  the  operator  should  be  able  to  isopleth  and  contour 
multiple  parameters  in  a  single  invocation  of  the  appropriate 
product  generation  function,  but  the  strawman  hierarchy  does 
not  provide  this  capability  because  it  is  not  known  how  many 
product  identifier  fields  must  be  respecified  in  order  to 
uniquely  identify  each  additional  parameter.  As  an  example, 
the  need  for  certain  product  identifier  fields  (such  as  the 
data  designator)  in  guaranteeing  product  uniqueness  should  be 
verified.  In  addition,  the  flexibility  needed  to  permit 
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Isoplethlng  and  contouring  of  parameters  with  different  base 
times,  forecast  times,  atmospheric  levels,  geographic  areas, 
and  product  types  may  limit  the  usefulness  of  this  capability. 


Horizontal  Analysis  Products 

(10)  The  requirement  to  display  topographic  map  data  could  be 
handled  by  allowing  the  user  to  switch  back  and  forth  between 
the  two  map  display  modes  whenever  a  map  appears  on  the 
screen. 

(11)  The  extrapolation  function  could  be  carried  out  as  follows: 

a)  The  operator  uses  a  DISPLAY  or  ISOPLETH  command  to 
display  a  horizontal  analysis  product; 

b)  The  operator  invokes  the  extrapolation  function  and 
picks  the  feature  to  be  extrapolated; 

c)  The  system  temporarily  displays  (possibly  as  monochrome 
overlays)  two  selected  earlier  versions  of  the  product, 
and  allows  the  user  to  pick  the  feature  of  interest; 
and 

d)  The  system  computes  and  displays  the  extrapolated 
position  of  the  feature  of  interest. 

(12)  The  ADVECTION  parameter  option  for  the  isopleth  function  could 
be  carried  out  as  follows: 

a)  Remain  at  the  appropriate  parameter  hierarchy  module 
(1.1.6. 1.1,  1.1.6. 1.2,  or  1.1. 6. 2. 1.1),  this  time 
disallowing  now  irrelevant  parameter  options 
(ADVECTION,  ADVECTED  FIELD,  and  ADD/SUBTRACT),  and 
allow  the  user  to  specify  the  advection  parameter  of 
interest ;  and 

b)  Continue  to  the  next  appropriate  module  of  the 
hierarchy  (1 . 1 .6 . 1. 1 . 1 ,  1.1. 6. 1.2.1,  or  1 . 1 . 6. 2 . 1 . 1 . 1) . 

(13)  The  ADVECTED  FIELD  parameter  option  for  the  isopleth  function 
could  be  carried  out  as  follows: 

a)  Remain  at  the  appropriate  parameter  hierarchy 

(1.1. 6. 1.1,  1.1. 6. 1.2,  or  1.1. 6. 2. 1.1),  this  time 
disallowing  now  irrelevant  parameter  options 
(ADVECTION,  ADVECTED  FIELD,  and  ADD/ SUBTRACT) ,  and 
allow  the  user  to  specify  the  advected  field  parameter 
of  interest; 
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b)  Allow  the  user  to  specify  the  desired  advection  time 
interval  (hierarchy  module  3.0);  and 

c)  Continue  to  the  next  appropriate  module  in  the 
hierarchy  (1.1. 6. 1.1.1,  1.1. 6. 1.2.1,  or  1.1. 6. 2. 1.1.1). 

(lA)  The  ADD/SUBTRACT  parameter  option  might  be  difficult  to 
implement  if  a  substantial  amount  of  generality  is  to  be 
accommodated.  For  example,  the  user  may  want  to  perform  the 
ADD/SUBTRACT  option  for:  a)  different  atmospheric  levels 
(e.g. ,  GPH  (500  mb)  minus  GPH  (1000  mb));  b)  different  FBD 
file  times  (e.g.,  TMP  (1200  GMT)  minus  TMP  (0000  GMT)); 
c)  different  UGDF  base  and  forecast  times  (e.g.,  TMP  (Base 
time  =  0000  GMT,  Forecast  interval  =  24  hours)  minus  TMP  (Base 
time  =  1200  GMT,  Forecast  interval  =  12  hours));  d)  different 
data  types  (e.g.,  a  comparison  of  predicted  UGDF  field  with  an 
observed  FBD  field);  and,  possibly  e)  different  parameters 
entirely  (e.g.,  TMP  minus  DPT).  If  all  but  the  last  option 
are  to  be  accommodated,  a  possible  way  to  implement  the  ADD/ 
SUBTRACT  parameter  option  is: 

a)  Remain  at  the  appropriate  parameter  hierarchy  module 
(1.1.6. 1.1,  1.1.6. 1.2,  or  1 . 1 . 6 . 2 . 1 . 1 ) ,  this  time 
disallowing  now  irrelevant  parameter  options 
(ADVECTION,  ADVECTED  FIELD,  and  ADD/SUBTRACT),  and 
allow  the  user  to  specify  the  name  of  the  first 
add/subtract  parameter  of  interest; 

b)  Cycle  through  to  hierarchy  module  1.1. 6. 1.1. 1.1.1, 

1.1. 6. 1.2. 1.1. 1.1,  or  1.1. 6. 2. 1.1. 1.1. 1.1.1,  allowing 
the  user  to  specify  additional  information  about  the 
first  add/subtract  parameter;  and 

c)  Return  to  hierarchy  module  1.1.6,  and  cycle  through  the 
entire  isopleth  module  (omitting  the  ISOPLETH  LEVEL, 
but  not  the  DATA  OVERRIDE  hierarchy  level),  allowing 
the  user  to  specify  the  second  add/subtract  parameter. 

The  system  should  prevent  the  user  from  attempting  to 
add/subtract  incompatible  parameters  (e.g.,  temperature  and 
pressure) . 

(15)  For  the  horizontal  analysis  and  cross  section  composite 

product  functions  (hierarchy  modules  1.1,  1.3,  1.4,  and  1.5), 
the  appropriate  product  background  (map  background  or 
appropriate  cross  section  path  outline)  must  appear  on  the 
display  screen  before  display  or  product  generation  functions 
can  be  executed.  The  product  produced  by  the  command  will  be 
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"overlayed"  with  the  existing  display  information  if  a 
mutually  compatible  product  background  already  appears  on  the 
screen;  otherwise,  an  error  will  occur.  An  existing  display 
can  be  cleared  by  the  CLEAR  command,  or  cleared  and  replaced 
by  a  new  product  background  via  a  DISPLAY  MAP  or  SELECT  PATH 
command.  In  the  latter  case,  in  a  multitasking  environment, 
the  system  could  then  proceed  to  display  the  new  product 
background  concurrently  with  operator-entry  of  subsequent 
commands . 

Vertical  Analysis  Products 

(16)  The  "specify  path"  branch  will  provide  information  such  as 
"stations"  and  "valid  time"  for  the  FED:  Distance  vs.  Log-P 
cross  section,  "station"  and  "number  of  previous  file  times" 
for  the  FED;  Time  vs.  Log-P  cross  section,  and  the  D,  AA,  TT, 
First-i,  and  Second-E  product  identifiers  for  the  UGDF: 
Distance  vs.  Log-P  cross  section. 

(17)  The  selection  of  endpoints  for  UGDF  cross  sections  is  probably 
best  carried  out,  after  an  input  is  given  for  hierarchy  module 
1.5.5  (REGIONAL  WINDOW/MESH  SIZE),  by  displaying  the  selected 
map,  superposed  with  a  grid  of  the  selected  mesh,  and  enabling 
the  user  to  interactively  select  the  grid  endpoints. 

(18)  The  requirement  for  operator  input  of  "valid  time"  for  the 
Skew-T,  Log-P  chart  and  the  FED:  Time  vs.  Log-P  cross  section 
is  interpreted  as  a  provision  to  indicate  how  many  previous 
file  times  are  to  be  included  with  the  current  file  time  in 
generating  the  appropriate  product. 

Loops,  Sequences,  and  Command  Files 

(19)  It  is  assumed  that  loops  and  sequences  will  be  composed 
entirely  of  vector  graphic  and/or  raster  scan  products. 

(20)  It  is  assumed  that  command  files  will  be  composed  of  either 
all  graphic  or  all  alphanumeric  commands.  Further,  for  a 
graphic  command  file,  the  commands  included  should  all  be 
valid  for  the  same  product  type.  If  this  criteria  is  not  met, 
the  display  screen  would  clear  when  product  types  were 
switched  (e.g,  if  Skew-T,  Log-P  commands  are  issued  following 
Horizontal  Analysis  Product  commands). 

(21)  For  consistency,  the  construction  and  modification  of  loops 
and  sequences  and  command  files  should  follow  the  same 
procedures  the  operator  would  use  to  individually  execute  the 
commands  to  be  included.  The  strawman  design  accommodates 


138 


this  by  the  use  of  START  and  STOP  commands.  All  commands 
issued  between  successive  START  and  STOP  commands  will  become 
part  of  the  loop,  sequence,  or  command  file  being  created. 

(22)  There  is  no  need  to  make  any  distinction  between  the  creation 
of  a  loop  and  the  creation  of  a  sequence  -  loops  and  sequences 
differ  only  in  the  way  they  are  run.  Provided  that  the  loop 
time  interval  is  specified  by  the  LOOP/SEQUENCE  module  (1.6), 
all  other  degrees  of  freedom  for  running  loops  and  sequences 
could  be  accommodated  by  three  buttons  allowing:  1)  forward 
sequencing;  2)  reverse  sequencing;  and  3)  start/stop  looping. 

(23)  Upon  completion  of  execution  of  a  command  file,  the  system 
should  place  the  user  at  the  hierarchy  module  that  is  the  root 
for  th''  type  of  graphic  product  created.  For  example,  if  a 
Formatted  Binary;  Time  vs.  Log-P  cross  section  is  generated  by 
a  command  file,  the  user  should  be  placed  at  hierarchy 
module  1.4  (CROSS  .SECTION  COMMAND)  following  completion  of 
execution  of  the  command  file.  This  feature  will  allow  the 
user  to  proceed  to  perform  other  functions,  such  as  graphic 
interaction,  on  the  displayed  product. 

Zoom 

(24)  Because  there  is  no  requirement  to  store  a  product  at  a  zoom  A 
ratio  other  than  1:1,  the  EXIT  option  of  the  zoom  A  hierarchy 
level  should  automatically  return  the  product  to  the  1:1  zoom 
A  ratio.  By  contrast,  because  a  product  can  indeed  be  stored 
at  a  zoom  B  ratio  other  than  1:1,  the  EXIT  option  of  the 

zoom  B  menu  should  not  alter  the  zoom  B  ratio  in  effect. 

(25)  A  strawman  concept  for  the  zoom  B  prioritization  for 
horizontal  analysis  products  is  that  the  "default"  reporting 
station  prioritization  and  the  "highest  displayable"  UGDF  plot 
prioritization  are  invoked  when  the  product  is  created.  The 
user  should  proceed  to  the  zoom  B  hierarchy  level  to 
subsequently  adjust  the  prioritizations  for  any  zoom  ratio 
(including  1:1). 


LIST  OF  ACRONYMS 


AA 

AAI 

AFCC 

AFOS 

AGDS 

ANSI 

ARQ 

ATC 

AWDS 

AWIS 

AWS 

BWS 

CAD/ CAM 
CB9 
C*I 
CDR 

D 

F 

FA 

FBD 

FCF 

FO 

FSED 

GF 

GKS 

GMT 

GPH 

ICAO 

ICD 

ISO 

UWC 

Me I DAS 
MM  I 

NOTAM 

NWS 

PROFS 


Geographic  Designator  (product  identifier  field) 

Aircraft  Accident  Investigation 

Air  Force  Communications  Command  (AFCC) 

Automation  of  Field  Operations  and  Services 
AWDS  Graphic  Development  System 
American  National  Standards  Institute 
Automatic  Response  to  Query 
Air  Traffic  Control 

Automated  Weather  Distribution  System 
Automated  Weather  Information  Systems 
Air  Weather  Service 

Base  Weather  Station 

Computer-Aided  Design/Computer-Aided  Manufacture 
Cumulonimbus  With  Anvil 

Command,  Control,  Communications,  and  Intelligence 
Critical  Design  Review 

Data  Type  Indicator  (product  identifier  field) 

File  Indicator  (product  identifier  field) 

Functional  Area 

Formatted  Binary  Data 

Flight  Control  Facility 

Flight  Operations 

Full-Scale  Engineering  Development 
Ground  Fog 

Graphical  Kernel  System 
Greenwich  Mean  Time 
Geopotential  Height 

International  Civil  Aviation  Organization 
Interface  Control  Drawing 
International  Standards  Organization 

Local  Area  Workchart 

Man-Computer  Interactive  Data  Access  System 
Man-Machine  Interface 

Notice  to  Airmen 
National  Weather  Service 

Prototype  Regional  Observing  &  Forecasting  Service 
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LIST  OF  ACRONMYNS  (continued) 


QC  Quality  Control 

RMSM  Removable  Magnetic  Storage  Media 

SDR  System  Design  Review 

SG  Snow  Grains 

SOW  Statement  of  Work 

SRR  System  Requirements  Review 

STS  Specialty  Training  Standard 

SWO/WWO  Staff  Weather  Officer/Wing  Weather  Officer 

TBS  Severe  Turbulence 

TMP  Temperature 

TSS  Tropical  Storm  -  Southern  Hemisphere 

TT  Data  Type  Subcategory  (product  identifier  field) 

UGDF  Uniform  Gridded  Data  Field 

WPH  Shower  During  the  Past  Hour 
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